Custom Query (69 matches)
Results (46 - 48 of 69)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #76 | fixed | SVN rev 361: FAT32.IFS doesn't display "." and ".." in FAT[/12/16/32] root directory | ||
| Description |
I have written myself this batch file to do a chkdsk run just in case a removable volume is corrupted: @echo off del d:\chkdsk.log>NUL & for %%D in (c: g: h: i: j: k:) do (if not exist %%D\. (echo Checking drive %%D & chkdsk %%D /F>>d:\chkdsk.log)) pause This batch file works fine if the volume is managed by JFS.IFS but "if not exist %%D\." always fails on a volume managed by FAT32.IFS even if that volume is not corrupted. That's because FAT32.IFS does not report the existence of the "." and ".." directories. |
|||
| #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. |
|||
| #47 | duplicate | Stuck system (ECS22 and ARCAOS) (replaces #46) | ||
| Description |
Since experiencing the stuck state (as I thought on ArcaOS) I have experimented with both CS and ARCAOS. The stuck states occur on both systems in all releases later than 913. I now have a file on a FAT32 formatted volume that causes a stuck state on either system when attempting to delete it (DEL comand) in a DOS window. This effect is (so far) 100% consistent and oersisted despite remaking the volume by copying the files and directories. Please let me know what diagnostic information would be useful. |
|||
