Messages in this thread | | | Date | Mon, 15 Feb 1999 19:49:31 -0500 (EST) | From | Alexander Viro <> | Subject | Re: rmdir of one's pwd |
| |
On Tue, 16 Feb 1999 Andries.Brouwer@cwi.nl wrote:
> 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/
| |