Custom Query (69 matches)
Results (10 - 12 of 69)
Ticket | Resolution | Summary | Owner | Reporter |
---|---|---|---|---|
#8 | invalid | Rexx script filled with all zeroes and chkdsk errors. | ||
Description |
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. |
|||
#11 | invalid | Removable as floppy support | ||
Description |
Currently only FAT can be used for Removable as floppy support. It would be good to be able to use FAT32 as many USB devices now ship this way. I don't know if this can be implemented in the IFS or if it would require an FLT or something else. I don't expect this will be trivial or quickly done but wanted to have the request on record. |
|||
#18 | invalid | Ability to at least read Windows long filenames on FAT32 | ||
Description |
MS holds several FAT-related patents specific to the storage of long filenames (see http://en.swpat.org/wiki/Microsoft_FAT_patents for links). However, none of those should preclude us from reading the Windows LFNs so that they don't show up as blah~1.ext. As we store LFNs differently, we could at least read the Windows LFNs and when saving to a new LFN, then store using our method. |