Opened 8 years ago
Closed 8 years ago
#20 closed defect (fixed)
Seems to corrupt partitions formatted with other filesystems
| Reported by: | erdmann | Owned by: | |
|---|---|---|---|
| Priority: | Feedback Pending | Milestone: | GA |
| Component: | IFS | Version: | |
| Severity: | medium | Keywords: | |
| Cc: |
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.
Change History (7)
comment:1 by , 8 years ago
comment:2 by , 8 years ago
I just tried to reproduce your trap -- inserted two FAT32 flash disks and a third one with JFS and HPFS logical partitions on it. Tried to have all them on boot -- nothing happens (they actually are not mounted on boot, so I need to do "lvm /rediscoverprm" for them to mount). And JFS partition is not hurted when I do CHKDSK on HPFS one. So, I see no problem here. Maybe, it is not FAT32 problem, or, there's no such problem with my current FAT32 versions (Lars, could you check alpha6 version?).
comment:3 by , 8 years ago
| Priority: | major → Feedback pending |
|---|
@Lars is this still true with latest alpha?
comment:4 by , 8 years ago
| Milestone: | → GA |
|---|
comment:5 by , 8 years ago
I'll reproduce the scenario and let you know if the problem is fixed with the latest alpha7 or not.
comment:6 by , 8 years ago
I retried with ftp://osfree.org/upload/fat32/fat32-0.10-alpha7.zip and latest file date of 20.10.2016 and I can no longer trigger this problem.
You can close the ticket, thanks !
comment:7 by , 8 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
closing as per request of the reporter
FS_MOUNT does not touch the volume, as it only reads partitions, not writes them. But I need to look closer, of course. Also, if I remember correctly, trunk is not workable. Something is not working, so I needed to roll back to some working revision, something like the revision, corresponding to version 0.9.13 (last version). I tried to merge trunk with my current branch, but something doesn't work and no success. I don't remember an exact reason, because it was some years ago. (you can see ifsmount-new.c file which is a not finished merge with trunk).