> criticize, but only to learn ;-) Seriously, if the stuff in /usr/man/man2
> is not intended to describe Linux kernel API (e.g. represents a relevant
> part of POSIX in man format - *good* thing to have somewhere) I am going
> to start man9 or man2L myself - I know enough *roff and VFS to do that ;-)
>
> I would be very happy.
OK, then. Manpages at 11 ;-) Not tonight - I'm way too low on caffeine
right now, but I'll probably have spare time this week.
> Could you clarify the situation?
>
> Well, I am the maintainer of the Linux man pages, but not the author,
> even though I wrote a number of them. So, if you contribute man pages
> about ext2 attributes or about capabilities or so, or anything else
> for that matter that you deem needs documenting, and at first sight
> your text looks reliable, I'll be very happy to include it in the
> man page collection.
>
> In this particular case, the string `immutable' does not yet occur in any
> man page. I am not going to add it to the rename.2 man page. There has to
> be a separate man page about these attributes, and once it exists we may
> consider adding references to it on other pages.
>
> Note that `immutable' is not POSIX, not even Linux, but ext2.
> Probably what you want is a page ext2-attributes.4 or so.
> There may be references from/to chattr.1 / lsattr.1.
Andries, actually immutable and append-only are *not* about ext2.
Any other ext2 attribute - yes, but not those two. They are set via the
same ioctl as the rest of ext2 attrs, but they are *very* different. To
start with, they are supplied not only by ext2fs, but also by ufs and...
msdos, vfat and umsdos. Kernel supports two generic attributes of inode (in
addition to 12-bit POSIX part). Ext2 simply maps two bits of on-disk
inode two those attributes, just as it does for s[ug]id, sticky and
rwxrwxrwx bunch. All responsibility of ext2 stops here. Ditto for UFS.
FAT-derived ones do not set append-only bit, but may be asked to set
immutable (from 'System' attribute of FAT directory entries). All logics
is in the main kernel - in VFS. So actually Linux has 14-bit permissions
on inodes instead of standard 12-bit ones. Just as not every filesystem
can use s[ug]id and sticky (heck, not every fs has idea of separate
execute bit, not to mention owner/group/world distinction) not every
filesystem uses these 2 bits.
It's not POSIX, right, but it's not ext2. It's Linux and *BSD.
And indeed it's not only rename(). It affects rmdir(), unlink(), mkdir(),
symlink(), link(), open(), create(), truncate(), ftruncate(). That is,
anything that modifies namespace (except mount()/umount()) and anything
that can lead to changes of file contents (write()/writev()/pwrite() is
not affected only because of O_APPEND being already in POSIX, ditto for
mmap()). The *only* reason why we are using ad-hoc ioctl() instead of
normal, honest chmod() being the width of mode_t. Widen it to 32-bit and
this pair will join the rest of its relatives in a moment.
As for the attributes and related stuff - maybe we need several
manpages in .2 or .7 describing namespace structure (regular files/
directories/symlinks/mounting), special files (devices/FIFOs/AF_UNIX sockets),
permissions and lookups (plain, creation and removal - each with the set
of error conditions and corresponding values). I don't really think that
.4 is relevant here. I'll try to write this stuff. IMHO lists of error
conditions in .2 share way too big parts (surprise, surprise) and this
duplication is *evil*. If we could write
EFOO, EBAR, EBAZ if lookup on source fails (see lookup(7))
... --- lookup on target --- (see lookup(7))
... --- removing source --- (see remove_link(7))
... --- adding target if didn't exist ---
(see add_link(7))
EFOO, EQUUX, EFRED if the target exists and can't be removed
(see remove_link(7))
EINVAL if move would create a loop
EPERM if the source is a directory, we need to
flip .. and do not have write permissions
EXDEV source and target on different filesystems
ENOTDIR ...
EISDIR ...
EBUSY ...
EMLINK ...
EIO ...
it would be much more readable. That is, operation-specific parts are
separated from the generic ones and for the later we give the list of
possible error values and refer to corresponding manpage.
Let's do it that way - I'll write the lookup/create/remove pages
and will either post them on l-k or email to you. Then there will be
something to talk about. In any case I'll look through fs-related part of
.2 and will compare it with the actual code.
Cheers,
Al
-
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/