Messages in this thread | | | Date | Sat, 26 Jun 1999 00:49:58 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: [RFC] File flags handling - proposal for API. |
| |
On Sat, 26 Jun 1999, Albert D. Cahalan wrote:
> >> and then you can read and write the flags with just one system > >> call. I do not want to extend on stat() yet again. > > With *old and *new being what? Raw fs-specific inode data? > Something with a version number or size?
Nope. For FL_VFS (or SOL_VFS, just for giggles) it's a bitmap of VFS-affecting fs-independent flags. A-la append-only, immutable, no-unlink, their user-level versions, etc. Filesystem may support some of them - depends on the type (as with SUID, etc.)
For specific filesystem - *narrow* value that filesystem wants to see. Narrow as in "32 bits". For ext2 and ufs it would be inode flags, for FAT - attributes (albeit without ability to change Directory bit).
> > OK. But there is one but - we definitely have flags on ext2, ufs and > > <urgh> FAT ("System" == Immutable). I'm more than sure that other > > FAT has attributes like "MICROS~1.HTM".
Eh? Elaborate, please.
> NTFS has a 4th time stamp.
Fsck, no. Not another OOB channel for whatever random bullshit somebody wants to push through. Not another ioctl() - we have enough mess already.
> HFS has type and creator data.
No. Way. In. Hell. It's *not* a support for forks - if you want Mac'n'dreck you know where to find it. Again, it's a *narrow* channel - here I completely agree with Linus. The goal being to reduce the bloody clutter, not to introduce one more dungheap a-la ioctl().
> > Hmm... Methink I know what should be done here: > > chflags(name, level, old, new) where level being either FL_VFS or > > FL_EXT2 or FL_UFS, etc. IOW, the scheme similar to setsockopt(). > > Um, might there be a VFS already? As in "mount -t vfs..."?
So they should make their namespace (if any) FL_V_WE_ARE_DUMB_POSERS_FS. And be roundly LARTed for letting marketdroids invent 'cute' names.
> There are already at least 3 XFS filesystems. FL_GENERIC is > less likely to be a filesystem name.
> Oh, be sure to use a 64-bit inode if you return that data.
I don't see any place for inumber there.
- 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/
| |