Custom Query (69 matches)
Results (19 - 21 of 69)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #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. |
|||
| #19 | fixed | Handle the case of disk driver, supporting strat1 only | ||
| Description |
It appears that fat32.ifs requires the disk driver with strat2 support, and it uses it in the cache code to queue the i/o requests. But it assumes that strat2 is supported, and we'll get a trap in FS_MOUNT in case it isn't. The drivers supporting strat1 only, do exist, for example, it is hd4disk.add driver for PAE ramdisk. It uses it because strat1 is simpler, and faster. Actually, hpfs.ifs works almost 10 times faster with strat1 switch given to hd4disk.add. So, we need to handle gracefully the case of the disk driver, supporting strat1 only. -- We can just refuse to mount if the disk driver is strat1 only. This should be easy, but the full support for using strat1 only is harder to implement (need to change the cache logic) |
|||
| #20 | fixed | Seems to corrupt partitions formatted with other filesystems | ||
| Description |
The driver seems to corrupt partitions that where formatted with other filesystems: on boot, I have a couple of USB sticks attached, 2 of these are formatted with FAT32, another one is partitioned with 2 partitions and formatted with JFS and HPFS respectively (yet another is partitioned with 1 partition and formatted with JFS but this is irrelevant for this problem). On this two partition stick, the HPFS partition is getting corrupted without having been accessed at all. Running chkdsk on this HPFS partition also kills the JFS partition. Normally, running chkdsk on that HPFS partition has never caused a problem. The only idea I have is that the changes done to FS_MOUNT entry point might be causing these problems. It's invoked for every partition for EVERY filesystem driver, so that might be the relation to other filesystem drivers and filesystems. I can also remember a problem in FS_MOUNT where the pDevCaps pointer was NULL where it should not have been in which case it was requeried in an alternative way (by the "ReturnDriverCaps?" function which I had implemented for exactly this purpose). This code was now removed from FS_MOUNT (for whatever reason). Running Ko Myung Hun's 9.13 version is not causing these problems. |
|||
