The ext2 flags are totally filesystem-specific and do not belong
in the general stat structure, unless you put them in a union.
UFS has incompatible flags, FAT has incompatible flags...
Things like the backup flag and the read-only flag do have analogues on
other filesystems. There really aren't that many new flag ideas under
the sun.... I very much doubt we'll run out in the near future, at
least as far as flags are concerned.
Yes, the 32-bit field won't hold a Macintosh-HFS-let's-put-10-megabytes-of-
unrelated-crap-in-the-resource-fork, but that's not what it's intended
for.
It seems BSD tied the stat structure to UFS. Oops. They live in a UFS
world though, while Linux supports all sorts of weird filesystems.
I don't think you'd want to fill the stat structure with NTFS data.
Exactly! Anything that's NTFS specific shouldn't go in struct stat.
Anything that's ext2fs or UFS specific shouldn't go in struct stat
either.
There are however flags which are in common across multiple filesystems.
Why should we use completely different interfaces for setting or getting
the immutable flag on an ext2 or UFS filesystem? Shouldn't they use the
same interface whether you are using an ext2 or UFS filesystem under
Linux? Of course!!
So therefore we should have an abstract attributes flags word in struct
stat. Note that this abstract attributes flag word is by design does
not reflect the any on-disk formatting of the flags word for *any*
filesystem, ext2fs or UFS, and this was by design. It is there for
abstract attribute flags for which there is some reason to be believe
might be shared by more than one filesystem in the future.
- Ted
-
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/