>> 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.
Integers are useful too. NTFS has 4 time stamps. (POSIX + DOS)
>> 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.
Yes, unless it goes in a union.
> Anything that's ext2fs or UFS specific shouldn't go in struct stat
> either.
I would think ext2-specific data could be useful.
> 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?
UFS has _two_ immutable flags with different properties. See the problem?
Solutions and non-solutions include:
a. ignore the problem as we do now
b. abuse foreign flag bits, giving them all ext2 behavior
c. use a union and/or type parameter
> Shouldn't they use the same interface whether you are using an ext2
> or UFS filesystem under Linux? Of course!!
That would be nice if they meant the same thing.
> 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.
OK. What about flags which are obviously filesystem-specific?
It would be nice to have a sane interface for them too.
-
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/