>>>> a bug in gtkpod or the kernel (FS Panic).
>>>Maybe an FS error on your iPod? Did you try to reformat or dosfsck it?
>> Even then, the filesystem code should handle corrupt filesystems more
>> gracefully.
>
>Mh, what's "more gracefully" in the light of fs corruption?
return -EIO;
through all instances back to userspace and keep returning EIO for all
future requests. But let the user still umount the device.
>The driver just
>blocked write access to avoid further damage caused by writing to an
>inconsistent file system which sound perfectly reasonable to me. Writing to
>a corrupted fs could cause anything to it, depending on the corruption, so
>better act safe than sorry...
The interesting part comes when the filesystem corrupts itself
(= the code corrupts the on-disk data), and/plus it does not
notice quickly enough.
Jan Engelhardt
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
