/hdd3 Mounted Read-only Automatically!

[daniel3000]

Hello,

on my SL-C3000 the hard drive partition for user data (/dev/hda3 -> /hdd3) is by default mounted rw,noatime type vfat.

However, sometimes in normal usage it is automatically remounted ro (readonly), so if I work on something and then want to save it, saving fails.

What setting / daemon or whatever can cause this and why?

I have the impression that this is triggered by write processes. If I don't do anything with the drive, it is not touched. If I write to the disk, especially from KO/PI, but I think I have seen it also when saving other files, it is immediately remounted ro, so that saving is impossible.

The drive is not full, there are about 388MB free.


I once discovered a similar behaviour when the PC Link setting is set to USB-Storage and pointing to the hard drive, so that the hard drive is visible when the Z is connected to an USB host. But I have switched that off, i.e. set to "PC-Link" with Advances USB / TCP/IP so that should not be the reason.

Thanks for any hint!

daniel

[Shawn]

I too  periodically have this problem with a 3100 (japanese rom)

Happens sometimes after I've transferred files from windows to the zaurus through usb.
Wish I knew the combination that does it, because I only notice it after working on a file and can't save it, which is too late.

[daniel3000]

I found that the source of the problem on my side is a corrupted FAT.
It seems to be corrupted in an area where it points to some KDEPIM/PI data files, so the problem occurs only when saving in KDEPIM/PI apps.

I could work around it by renaming the directory and copying the contents (read access works well) to a new dorectory with the old name.

But I cannot delete the old directory, because as soon as I try to access it for writing (i.e. deleting), the drive is remounted readonly, dmesg says "filesystem panic, FAT error" and something about access to the drive beyond the drive limits.

fsck.vfat finds a problem and pretends to fix it, but next time I run fsck.vfat it finds the error again.

Either I'll need to re-create the file system entirely, or I have to open the Z,  dismount the microdrive and put it in a windows PC to run scandisk against the drive.

Or is there any other way to fix such a problem whic fsck.vfat is obviously not able to fix?

daniel