What steps will reproduce the problem? 1. Format USB drive with FAT32 2. Install grub4dos 3. Copy 150 short-filename 8.3 files to root folder (e.g. xp i386 files) 4. boot to grub4dos console and type ls /

only approx 128 files listed

Now if you delete 50 files from the USB drive, and then copy one new file (e.g. NEW.TXT) to the USB drive, it is not listed by grub4dos.

Perhaps grub4dos only searches first 128 entries including deleted entries?

If long-filename files are used then the number of entries listed by grub4dos is even smaller (which is expected). So in some cases you can only store 50 long-filename files in the root and if you delete them and copy new files over, they are not listed by grub4dos!

What is the expected output? What do you see instead?

FAT32 can support more than 128 files in the root. Even if limit of 128 applies, deleted (E5h) entries should be ignored.

What version of the product are you using? On what operating system? 45c 2013-03-12

Please provide any additional information below. sub-folders are OK, I think this is limitation of FAT16 code.

I have not tested FAT16 at all, but DOS has 128 limit on FAT16.

This windows .cmd batch files reproduces this issue:

format USB drive as FAT32 install grub4dos + grldr run cmd file from Windows console (assumes USB drive is H:)

set a=0

:LOOP set /a a=a+1 echo t > h:\%a%.txt if "%a%"=="130" goto :P goto :LOOP

:P del H:\126.txt del H:\125.txt del H:\124.txt

copy H:\1.txt H:\NEW1.txt copy H:\2.txt H:\NEW2.txt copy H:\3.txt H:\NEW3.txt

Just tested FAT16 and it seems OK in FAT16! After running batch file, files are listed under grub4dos correctly.

Just noticed that it only does this when the USB drive is prepared with RMPrepUSB!

This a problem in RMPrepUSB Format FAT32 code - sorry for trouble! PLEASE CLOSE!

The problem was traced to the first cluster entries - see http://reboot.pro/topic/18339-fat32-bug-in-grub4dos/#entry169751 for details I eventually traced it to the first 3 cluster entries!!

On a volume formatted by Windows these were: F8 FF FF 0F FF FF FF 0F FF FF FF 0F on an RMPrepUSB formatted volume they were: F8 FF FF FF FF FF FF FF FF FF FF FF

this apparently caused the problem!!??