> So the question is, what changed in VFAT support from 2.2.10->2.2.11?
> Is there some magic switch I can use to revert to legacy behavior?
>From patch-2.2.11:
+++ linux/fs/fat/dir.c Mon Aug 9 12:04:41 1999
@@ -9,7 +9,7 @@
*
* VFAT extensions by Gordon Chaffee <chaffee@plateau.cs.berkeley.edu>
* Merged with msdos fs by Henrik Storner <storner@osiris.ping.dk>
- * Plugged buffer overrun in readdir(). AV
+ * Rewritten for constant inumbers. Plugged buffer overrun in readdir(). AV
*/
AIUI - and I may well be wrong, hopefully Al Viro will correct me if so (I've
dropped him from the cc: list 'cos I'm sure he's sick to death of this subject
by now):
FAT keeps /all/ of its metadata inside directories, and is thus Broken as
Designed.
The old behaviour of the Linux fat driver was to assign inode numbers based on
the metadata location -- this meant that the inode number was not constant
across rename(). Not only did this louse up exporting fat filesystems over
NFS (I think), but it also meant that there were a not inconsiderable number
of races inside the FAT driver. These had been seen to cause real-life data
corruption.
I'm not sure what the new code does, but IIRC it guarantees that inumbers will
not change while the file is open. I don't know whether they can change if the
file is shut and the inode uncached, but the fs is still mounted; I suspect
they can. I'm certain they will change across mounts. While this is not good,
it's much, much better.
On Mon, 19 Jul 1999, Alexander Viro wrote:
"On Mon, 19 Jul 1999, Alan Cox wrote:
> o FAT now uses cluster numbering for inode info
It doesn't. It generates inumbers on the fly. Cluster numbering is
unusable for that - truncate() *shouldn't* change inumber. FAT *has* no
file invariants that would survive (a) rename, (b) truncate(), (c) write
and (d) umount. Of all those umount give the least pain wrt races. New
code guarantees constant inumbers for opened files.
The bottom line - inumbers on FAT will suck anyway. There is no
inodes in normal sense. And inumbers changing after reboot are *much*
better than exploitable races. On FAT usage of (old) inumbers for any
backup stuff was broken - rename() would go unnoticed."
There's more info in
<Pine.GSO.4.10.9907201115360.4963-100000@weyl.math.psu.edu>, if you want.
> Normally I don't come here begging for help, but this time I am stuck.
> Rolling back to 2.2.10 does not help me or other amanda users long term.
I'm afraid the only long term is solution is to stop using FAT. If you have
no other operating systems accessing the data, convert the partition to
something sane (ext2 would be my recommendation). If you have, let that
operating system do the backups. Hell, even NTFS has inode numbers (though
they don't call them that). Let's not get into the long/short filename
backup issues.
To quote Mr. Viro once more: "yes, FAT is in sore need of pointed stick, mallet
and garlic; no, even its authors can't kill the bloody thing and they would
*like* to do that."
--
"People get annoyed when you try to debug them."
-- Larry Wall
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/