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.

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.

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.

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.

Nice suggestion, thanks.I opened an issue/request in Github: https://github.com/c...4dos/issues/128Personally, 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.

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 of objects in a filesystem.

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.

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 not that it cannot find a directory on FAT32, but rather that it can find it on NTFS.

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).

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).

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 , 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.

...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/