Jump to content











Photo
- - - - -

Grub4dos does not find files/folders in FAT32 volume

grub4dos fat32 find

  • Please log in to reply
23 replies to this topic

#1 ner0

ner0

    Member

  • Members
  • 48 posts

Posted 13 November 2016 - 02:44 AM

Hello,

 

I recently tried using Grub4dos within a FAT32 partition and I couldn't.

I tried several versions of Grub4dos, from 0.4.4 to latest 0.4.6 and the behavior was always the same.

So, the problem, as described in the title, is that when I try to find a file or folder within a FAT32 volume it always returns a "Error 15: File not found" message. For example:

grub> find /iso
Error 15
grub> ls (hd0,4)/iso
iso
grub > geometry (hd0)
drive 0x80(LBA): C/H/S=7832/255/63, Sector Count/Size=125821080/512
  Partition num: 0, active, Filesystem type is ntfs, partition type 0x07
  Partition num: 1,  Filesystem type is ntfs, partition type 0x07
  Partition num: 4,  Filesystem type is fat32, partition type 0x0B
I have formatted the FAT32 partition using MiniTool Partition Wizard Free 9.1 (ISO), but I also tried deleting the partition and reformatting it under Windows 10. In both cases the same happens, Grub4dos "find" command does not find files or folders. If I format in NTFS then everything works great. 
 
This is quite odd and I couldn't find any info on a similar issue.
I would appreciate suggestions as to why this is happening. I can live without FAT32 but it's so weird that I would like to get to the bottom of it.
 
Thanks!


#2 tinybit

tinybit

    Gold Member

  • Developer
  • 1051 posts
  •  
    China

Posted 13 November 2016 - 05:10 AM

With this:

find /iso

I guess your "iso" is a folder, not a file.

 

Generally grub4dos cannot deal with folders. But in some cases or with some filesystems, the folder is (partially) supported (by grub4dos).

 

You may report the issue(or as a feature request) and see if the maintainers could fix it.



#3 tinybit

tinybit

    Gold Member

  • Developer
  • 1051 posts
  •  
    China

Posted 13 November 2016 - 11:36 AM

Anyway, Yaya compiled a version and wish someone can test to confirm whether it works. Here is the download link:

http://bbs.wuyou.net...jl8MHwzODM2NzE=

 

I am sorry but only registered users could download files. I am trying to upload it here, please wait a moment.

 

Sad! I simply cannot upload the file

grub4dos-0.4.6a-2016-11-13.7z        size 284 KB

 

When the upload process goes 100%, it always says, "No file was selected for upload", and failed!

 

OK, I finally uploaded here:

 

http://tinybit.chena...a-2016-11-13.7z



#4 ner0

ner0

    Member

  • Members
  • 48 posts

Posted 13 November 2016 - 03:25 PM

With this:

find /iso

I guess your "iso" is a folder, not a file.

 

Generally grub4dos cannot deal with folders. But in some cases or with some filesystems, the folder is (partially) supported (by grub4dos).

 

You may report the issue(or as a feature request) and see if the maintainers could fix it.

 

Yes, "iso" is a folder in this case.

I did not know that handling folders was not fully supported, mostly because under NTFS I never found any limitation.

In any case, I did try the version you uploaded and it works flawlessly on FAT32 so far, folders included.

 

Thank you!



#5 steve6375

steve6375

    Platinum Member

  • Developer
  • 6462 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted 13 November 2016 - 03:57 PM

This is a bug I reported years ago but it was never fixed.

exFAT and ext also needs to be tested as well as NTFS.

In E2B I use

ls (bd)/_ISO/AUTO/ > (md)0x9F00+1 && checkrange 1:-1 read 0x13E0000 > nul

which works on all filesystems



#6 ner0

ner0

    Member

  • Members
  • 48 posts

Posted 13 November 2016 - 04:05 PM

This is a bug I reported years ago but it was never fixed.

exFAT and ext also needs to be tested as well as NTFS.

In E2B I use

ls (bd)/_ISO/AUTO/ > (md)0x9F00+1 && checkrange 1:-1 read 0x13E0000 > nul

which works on all filesystems

 

Was this ancient bug report related to this post by any chance: http://reboot.pro/to...b-not-grub4dos/

 

Anyway, 'ls' worked fine in my case, the problem was the 'find' command (possibly others). Didn't test on ExFAT or EXT2, NTFS seems to be working though. Curiously, I had to resort to the command you demonstrated in order to check if a folder is empty or not.

By the way, great work at "rmprepusb.com", the info you aggregate there has helped tons in learning to navigate Grub4dos.


Edited by ner0, 13 November 2016 - 04:05 PM.


#7 steve6375

steve6375

    Platinum Member

  • Developer
  • 6462 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted 13 November 2016 - 04:41 PM

No, I reported the bug years ago on the old chenall site (which I think has gone now?).



#8 steve6375

steve6375

    Platinum Member

  • Developer
  • 6462 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted 13 November 2016 - 05:16 PM

The find command is defined as 'Search for the filename FILENAME...'  it is not supposed to find folders

So I am not sure that changing it's behaviour is a 'good thing'.

For instance, if I wanted to find a file called ISO, then  find /ISO would work, but if there was a folder named \ISO then it would not return true.

This is the defined and expected result.

The new version of grub4dos returns 'true' for both a file and a folder named 'ISO' - this is not the correct action...



#9 ner0

ner0

    Member

  • Members
  • 48 posts

Posted 13 November 2016 - 05:30 PM

The find command is defined as 'Search for the filename FILENAME...'  it is not supposed to find folders

So I am not sure that changing it's behaviour is a 'good thing'.

For instance, if I wanted to find a file called ISO, then  find /ISO would work, but if there was a folder named \ISO then it would not return true.

This is the defined and expected result.

The new version of grub4dos returns 'true' for both a file and a folder named 'ISO' - this is not the correct action...

 

I agree with your reasoning, but what about the current case where the same file can exist in different partitions?

Isn't it essentially the same thing, that you get multiple results?

 

If it were up to me I would make a distinction within find where a slash terminated path would be interpreted as a folder and anything else would be interpreted as a file, if that is even possible without much work.



#10 steve6375

steve6375

    Platinum Member

  • Developer
  • 6462 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted 13 November 2016 - 05:37 PM

Assuming there is an empty folder \ISO...

On a FAT32 volume, ls /ISO returns true and ls /ISO/ returns true

On an NTFS  and exFAT volume, ls /ISO returns true but ls /ISO/ returns false on an empty folder

This behaviour is not fixed by the new grub4dos version.


Edited by steve6375, 13 November 2016 - 05:40 PM.


#11 steve6375

steve6375

    Platinum Member

  • Developer
  • 6462 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted 13 November 2016 - 05:46 PM

P.S.  Under grub4dos

ls /a

lists all files or folders beginning with a. The help text for the command  ls just says

'List file or directory'

 

:dubbio:



#12 ner0

ner0

    Member

  • Members
  • 48 posts

Posted 13 November 2016 - 05:49 PM

P.S.  Under grub4dos

ls /a

lists all files or folders beginning with a. The help text for the command  ls just says

'List file or directory'

 

:dubbio:

 

That is part of the problem with 'ls' command in FAT filesystems.

What I found to be the issue is that 'ls' will return true whenever the beginning of the path exists.

For example, a folder named 'folder' exists:

grub > ls /folder > nul && echo true
true
grub > ls /fo > nul && echo true
true


#13 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13329 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 13 November 2016 - 05:56 PM

Semi-random thought, but maybe having the grub4dos chaecking for file nul or better nul.ext *like* the "IF EXIST" in  batch:

http://xset.tripod.com/tip5.htm

http://blogs.msmvps....with-same-name/

 

Would leave the thing "kosher" (finding FILEs and NOT directories) while satisfying the request. :unsure:

 

:duff:

Wonko



#14 ner0

ner0

    Member

  • Members
  • 48 posts

Posted 13 November 2016 - 07:27 PM

Semi-random thought, but maybe having the grub4dos chaecking for file nul or better nul.ext *like* the "IF EXIST" in  batch:

http://xset.tripod.com/tip5.htm

http://blogs.msmvps....with-same-name/

 

Would leave the thing "kosher" (finding FILEs and NOT directories) while satisfying the request. :unsure:

 

:duff:

Wonko

 

Nice suggestion, thanks.

I opened an issue/request in Github: https://github.com/c...4dos/issues/128

Personally, I think that the forward slash distinction/delimiter feels more intuitive than adding '/nul.ext', but either way what matters is allowing to find both types and distinguishing between them.


Edited by ner0, 13 November 2016 - 07:30 PM.


#15 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13329 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 13 November 2016 - 08:10 PM

Nice suggestion, thanks.
I opened an issue/request in Github: https://github.com/c...4dos/issues/128
Personally, I think that the forward slash distinction/delimiter feels more intuitive than adding '/nul.ext', but either way what matters is allowing to find both types and distinguishing between them.

Yes, the final forward slash would do as well :), but then the "find" won't be anymore looking for a "file", the suggestion was to keep that definition still valid, the other option (discussed in the given link), i.e.:
find /iso/.
would be IMHO even better, as the "." as "itself" or "dot directory" is well known on both Windows and Linux, but it would imply that the find looks not for files only (marginal issue of course, as long as it works and can distinguish a file from a directory).
As I see it (in my perverted mind) "/iso/" is a (relative) path, while "/iso/." is a directory.

:duff:
Wonko

#16 ner0

ner0

    Member

  • Members
  • 48 posts

Posted 13 November 2016 - 08:17 PM

I don't think I follow your logic, why do you think that the forward slash solution would prevent any of the current functionality. As far as I know, you search a file like this:

find /iso

But never like this:

find /iso/

So, my question is why would the dot add any significance?

I'm not an avid Linux user so I'm sorry if I'm not taking into account any standard usage of /., although I do know the opposite ./


Edited by ner0, 13 November 2016 - 08:18 PM.


#17 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13329 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 13 November 2016 - 08:28 PM

So, my question is why would the dot add any significance?
I'm not an avid Linux user so I'm sorry if I'm not taking into account any standard usage of /., although I do know the opposite ./

Sorry, we are cross posting.

Forget Linux (for the moment).
Open Windows command prompt:





MD mydir
dir mydir

You will have an output *like*:
 





13/11/2016  21.21    <DIR>          .
13/11/2016  21.21    <DIR>          ..

The "dot directory" is there alright.

It doesn't change anything, of course, as said in my perverted mind anything that ends with a slash (or backslash) is a path, and not a file or a directory, something that is alphanumeric can be both a file or a directory, something that ends in /. can only be the "dot directory", as you cannot have a file that is just "." normally.

If you prefer, the ending slash :) will work fine but it is conflicting with my mental map :w00t: of objects in a filesystem.

 

:duff:

Wonko



#18 ner0

ner0

    Member

  • Members
  • 48 posts

Posted 13 November 2016 - 08:45 PM

I don't think we are cross posting.
I still fail to see the relevance of the dot, even though I understand that any current OS will interpret it.
One cannot have a file that is just ".", normally, as you correctly noted, but the same is true for the forward-slash, files (or folders) cannot contain it in their name, no matter how many alphanumeric characters you throw at it. And so, both in Windows and Linux, using forward-slash and dot or just forward-slash results in exactly the same thing.
 
If we are saying that forward-slash and dot should be accepted also, then I have nothing to say against.
But if we have to decide between one or the other, well... my argument here is that adding one more character serves no purpose, possibly over complicates.
 
As I said before, I'll be more than happy to have at least one of those two options.  :good:

Edited by ner0, 13 November 2016 - 08:48 PM.


#19 tinybit

tinybit

    Gold Member

  • Developer
  • 1051 posts
  •  
    China

Posted 14 November 2016 - 12:27 AM

I seem to remember that not all filesystems have the "." and ".." notion, specifically, iso9660, as well as a number of linux filesystems.



#20 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13329 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 14 November 2016 - 10:18 AM

Another option could be an added option to the command (which will need to have its help lines updated):

find --dir /iso

Still, IMHO and still in my perverted mind, the actual problem is paradoxically :w00t: not that it cannot find a directory on FAT32, but rather that it can find it on NTFS. :ph34r:

I mean, as Steve6375 stated, IF the command is intended to find files, it should find files (and not directories).

 

More generally, if you create a directory (and leave it empty) there is actually no real reason to look for it if not - maybe - in some rare and marginal cases, if you want a "tag" file to identify a volume, use a "tag file" (and not a "tag directory"), otherwise you are normally looking for a file inside the directory (as an example to later chainload the file).

 

 

:duff:

Wonko



#21 ner0

ner0

    Member

  • Members
  • 48 posts

Posted 14 November 2016 - 10:42 AM

I mean, as Steve6375 stated, IF the command is intended to find files, it should find files (and not directories).

 

More generally, if you create a directory (and leave it empty) there is actually no real reason to look for it if not - maybe - in some rare and marginal cases, if you want a "tag" file to identify a volume, use a "tag file" (and not a "tag directory"), otherwise you are normally looking for a file inside the directory (as an example to later chainload the file).

 

The original purpose of the command isn't a constraint, for some odd reason the command was not named 'findfiles', there is no real reason to champion this exclusivity to find files and not folders, they shouldn't be mutually exclusive. The usefulness of the 'find' command is neither that it finds files, or folders, it is so that it provides a reference point within the filesystem of any given device's partition.

 

Since the command has been successfully in use for so many years we have to assume that the current conversation is aiming at an improvement which would fit those rare and marginal cases. After all, it was a marginal case that led me to create this post, currently I have to create a tag file because I know that the target will not contain any files whatsoever.

 

As for the paradox behavior between FAT and NTFS, I'm hesitant in claiming which is right. Not finding folders in FAT or finding them in NTFS. If you also take the 'ls' command into consideration you will there too observe a different behavior between FAT and NTFS. On NTFS it seems to work as intended whereas in FAT it returns results even for partial searches (as mentioned somewhere in this topic).



#22 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13329 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 14 November 2016 - 11:44 AM

As for the paradox behavior between FAT and NTFS, I'm hesitant in claiming which is right. Not finding folders in FAT or finding them in NTFS. If you also take the 'ls' command into consideration you will there too observe a different behavior between FAT and NTFS. On NTFS it seems to work as intended whereas in FAT it returns results even for partial searches (as mentioned somewhere in this topic).

So am I :dubbio: , I guess that the difference is *somehow* "embedded" in the differences between FAT and NTFS (and possibly EXT2/3/4 or ISO and other filesystems, like UDF), without saying which one is the "right" behaviour, the aim should be to have the same, documented one, on ALL filesystems, whether it is "right" or "wrong" is IMHO secondary to "coherence".

Another small "queerness" of grub4dos is the CaSe SeNsItIvEnEsS which is different on different filesystems.

 

:duff:

Wonko

 

P.S.: Before I forget, the (external) module fat:

http://www.rmprepusb...ubutils#TOC-fat

may be able to solve the problem (if we agree that the behaviour on FAT is "an exception")? :unsure:



#23 steve6375

steve6375

    Platinum Member

  • Developer
  • 6462 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted 15 November 2016 - 09:13 AM

...If you also take the 'ls' command into consideration you will there too observe a different behavior between FAT and NTFS. On NTFS it seems to work as intended whereas in FAT it returns results even for partial searches (as mentioned somewhere in this topic).

AFAIK, ls for a partial file or folder works the same way for FAT32 and NTFS. There is no difference. The difference is only for empty folders when using /xxx/ 



#24 ner0

ner0

    Member

  • Members
  • 48 posts

Posted 15 November 2016 - 09:53 AM

AFAIK, ls for a partial file or folder works the same way for FAT32 and NTFS. There is no difference. The difference is only for empty folders when using /xxx/ 

 

You are completely right, my mistake.







Also tagged with one or more of these keywords: grub4dos, fat32, find

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users