Custom Query (69 matches)

i found this lib in the internet

​http://code.google.com/p/fullfat/

Maybe this is a good base to build a improved version of this.

Hi, I use ECS1.2R and XP on the same machine. Only ECS has access to the www, so files I need for XP are only downloaded with ECS and stored with the installed fat32.ifs directly at the fat32 drives accessible under both systems.

Since longer time and trying different versions of fat32 (including 0.9.13 latest) I wondered that the downloaded files under XP are corrupt. Selfexpanding exe's are stopping with a CRC error or zip files cannot be expand.

Under ECS I use different versions of Seamonkey (latest 1.1.13)

On my formerly PC I had sometimes the same problems.

I have done some experiments: Downloading the file: ​http://startdownload.filefront.com/4286905//6fe471f91cdc109738f8eac44a258057618d7941c6ca8a291bbc33ef2fe926a0a3cdf95c098932f4// (should be project_51.zip ~130MB) direct to a fat32 partition

and a 2nd download to a JFS patition

results in the following:

Download to FAT32 drive: J:\>md5suml project_51.zip 9935917E3288FF884E9B595280BBBCCD project_51.zip filesize 131127388 Bytes

Archive: J:/project_51.zip

inflating: pro51.PK3 error: invalid compressed data to inflate inflating: readme.txt

ERROR

Download to JFS drive: F:\>md5suml project_51.zip 6D6A29E52F1055886A4271E53C3FB968 project_51.zip filesize 131127388 Bytes

Archive: F:/project_51.zip

inflating: pro51.PK3 inflating: readme.txt

OK

So I have written a little file comparison tool. It compares the good and the wrong file and logs all issues. See the attached files. Each line shows the adress, databyte good, databyte bad, total error count and the nummer of continued errors in follow. Please watch the follows carefully!

If I copy such larger files from HPFS or JFS to a FAT32 drive with a filecommander, like FC220, no problem occurs. With my 2Mbit www connection the files are written only slow while downloading them. May be a small buffer allocation problem in the IFS or cachef32.exe?

Problem with a Rexx script on a FAT32 volume.

After a number of cycles of updating and execution a Rexx script the script file was 'suddenly' completely filled with hex zeroes. For editing of this type of files I usually use Tim Baldwin's T2 editor (now called Tedit) which never failed on me. I experienced the problem for the first time after I migrated to Fat32.ifs 0.9.13, but when I went back to 0.9.12 (of the eCS 2.0 RC5 CD) it appeared again. I must say that I seldomly use a FAT32 volume to directy edit and execute Rexx scripts. So the cause of the problem may have been there all the time but I never hit it. After I moved the file to a JFS volume where it did not appear anymore. During xcopy (/H/O/T/S/E/R/V) of the directory with the all-zero Rexx script xcopy terminated on this file. Chkdsk /F reported lost clusters and recoverd three files (each the size of the allocation uniut: 32K), and in each I found back the origical Rexx script. Although it occurred three times I'm not sure if I can reproduce the problem. But even if I can what does it prove? I suspect Fat32.ifs is the failing component, but how can be sure? Which other relevant information could be collected? Since I have a work-around (moving the file to a JFS volume) I have marked it as 'minor' priority.

Regards, Rob.