rsenn / grub4dos-chenall

Automatically exported from code.google.com/p/grub4dos-chenall
0 stars 0 forks source link

grub4dos can only access first 128 file entries in root of FAT32 drive #124

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
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.

Original issue reported on code.google.com by Steve6375 on 20 Mar 2013 at 12:23

GoogleCodeExporter commented 9 years ago
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

Original comment by Steve6375 on 20 Mar 2013 at 12:34

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

Original comment by Steve6375 on 20 Mar 2013 at 1:01

GoogleCodeExporter commented 9 years ago
Just noticed that it only does this when the USB drive is prepared with 
RMPrepUSB!

Original comment by Steve6375 on 20 Mar 2013 at 1:07

GoogleCodeExporter commented 9 years ago
This a problem in RMPrepUSB Format FAT32 code - sorry for trouble! PLEASE CLOSE!

Original comment by Steve6375 on 20 Mar 2013 at 3:16

GoogleCodeExporter commented 9 years ago
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!!??

Original comment by Steve6375 on 20 Mar 2013 at 6:33

GoogleCodeExporter commented 9 years ago

Original comment by tinyb...@gmail.com on 20 Mar 2013 at 9:58