andrew@alice.uucp (Andrew Hume) (03/20/90)
From: andrew@alice.uucp (Andrew Hume) the posix 1003.1 standard has cleverly evaded naming of bits in the mode field of the stat structure. it does this by defining tests (like S_ISDIR(mode) rather than (mode&S_IFMT)==S_IFDIR). the question is, how do people deal with sym links? I simply added a S_ISLNK macro but would prefer to go with the flow if there is one. Volume-Number: Volume 19, Number 11
std-unix@longway.TIC.COM (Moderator, John S. Quarterman) (03/21/90)
From: Clive Feather <uunet!relay.EU.net!ixi!clive> In article <580@longway.TIC.COM> std-unix@uunet.uu.net writes: > The posix 1003.1 standard has cleverly evaded naming of bits > in the mode field of the stat structure. it does this by > defining tests (like S_ISDIR(mode) rather than (mode&S_IFMT)==S_IFDIR). > the question is, how do people deal with sym links? I simply > added a S_ISLNK macro but would prefer to go with the flow > if there is one. There is a set of changes to the standard being proposed under the title 1003.1b (the copy I have is draft 0.1, May 19, 1989). This adds the test macro S_ISLNK(m), and the function lstat(). stat() and lstat() differ only in that stat() never returns information about a symbolic link, whereas lstat() does. Because you cannot open a symbolic link, fstat() is like stat() here. The draft defines two new functions: int readlink (char *path, char *buf, int buf_size); int symlink (char *target_path, char *symlink_path); The functions that operate on links rather than the file pointed to are: lstat() readlink() rename() remove() rmdir() symlink() unlink() The effects of the following functions form an open issue: chown() chmod() link() utime() -- Clive D.W. Feather | IXI Limited | +44 223 462 131 (v) clive@ixi.co.uk | 62-74 Burleigh Street | +44 224 462 132 (fax) ...!uunet!ixi!clive | Cambridge U.K. |----------------------------- | CB1 1OJ | Silly quote being thought up Volume-Number: Volume 19, Number 17
std-unix@longway.TIC.COM (Moderator, John S. Quarterman) (03/22/90)
From: Donn Terry <uunet!hpfcrn.fc.hp.com!donn> >From: andrew@alice.uucp (Andrew Hume) >the posix 1003.1 standard has cleverly evaded naming of bits >in the mode field of the stat structure. it does this by >defining tests (like S_ISDIR(mode) rather than (mode&S_IFMT)==S_IFDIR). >the question is, how do people deal with sym links? I simply >added a S_ISLNK macro but would prefer to go with the flow >if there is one. This is exactly the kind of thing that is being done in 1003.1b, where symbolic links are being addressed. The current draft even uses the same spelling you do. Donn Terry (NOT speaking in any official way) Chair of 1003.1 Volume-Number: Volume 19, Number 16
std-unix@longway.TIC.COM (Moderator, John S. Quarterman) (03/22/90)
From: Doug Gwyn <uunet!smoke.brl.mil!gwyn> In article <580@longway.TIC.COM> std-unix@uunet.uu.net writes: >From: andrew@alice.uucp (Andrew Hume) >the posix 1003.1 standard has cleverly evaded naming of bits >in the mode field of the stat structure. it does this by >defining tests (like S_ISDIR(mode) rather than (mode&S_IFMT)==S_IFDIR). >the question is, how do people deal with sym links? I simply >added a S_ISLNK macro but would prefer to go with the flow >if there is one. I think that would be the most obvious name for such a macro. Unfortunately, so far as I can tell IEEE Std 1003.1-1988 fails to stake out portions of macro name space for headers such as <fcntl.h> (O_*) and <sys/stat.h> (S_*). (I had thought that it had, but I can't seem to find such provisions now; 2.8.2's definition of the action of _POSIX_SOURCE was supposed to support this.) >From the point of view of 1003.1, S_ISLNK() is not very useful, because both stat() and fstat() treat symbolic links as "transparent", and 1003.1 doesn't mention lstat() which is the function for which S_ISLNK() has a real use. Probably the best solution for implementors is along these lines: /* <sys/stat.h> */ ... #define _S_IFMT 0170000 /* type of file: */ #define _S_IFDIR 0040000 /* directory */ #define _S_IFCHR 0020000 /* character special */ #define _S_IFBLK 0060000 /* block special */ #define _S_IFREG 0100000 /* regular */ #define _S_IFLNK 0120000 /* symbolic link */ #define _S_IFSOCK 0140000 /* socket */ #define _S_IFIFO 0010000 /* fifo */ #define S_ISBLK(mode) (((mode) & _S_IFMT) == _S_IFBLK) #define S_ISCHR(mode) (((mode) & _S_IFMT) == _S_IFCHR) #define S_ISDIR(mode) (((mode) & _S_IFMT) == _S_IFDIR) #define S_ISFIFO(mode) (((mode) & _S_IFMT) == _S_IFIFO) #define S_ISREG(mode) (((mode) & _S_IFMT) == _S_IFREG) #ifndef _POSIX_SOURCE /* enable "common usage" extensions */ #define S_ISLNK(mode) (((mode) & _S_IFMT) == _S_IFLNK) #define S_ISSOCK(mode) (((mode) & _S_IFMT) == _S_IFSOCK) #define S_IFMT _S_IFMT #define S_IFDIR _S_IFDIR #define S_IFCHR _S_IFCHR #define S_IFBLK _S_IFBLK #define S_IFREG _S_IFREG #define S_IFLNK _S_IFLNK #define S_IFSOCK _S_IFSOCK #define S_IFIFO _S_IFIFO #endif /* !_POSIX_SOURCE */ ... Volume-Number: Volume 19, Number 18
std-unix@longway.TIC.COM (Moderator, John S. Quarterman) (03/22/90)
From: Ronald Guilmette <uunet!ics.UCI.EDU!rfg> In article <586@longway.TIC.COM> Clive Feather <uunet!relay.EU.net!ixi!clive> writes: > >The functions that operate on links rather than the file pointed to are: > > lstat() readlink() rename() remove() rmdir() symlink() unlink() > >The effects of the following functions form an open issue: > > chown() chmod() link() utime() Those may be an "open issue" as far as POSIX is concerned, but I call them an "open wound" as far as actual UNIX implementations are concerned. I get unhappy each time I need to do something like an lchmod() and realize (again) that there is no such thing. Sigh :-( // rfg Volume-Number: Volume 19, Number 19
bvs@amdcad.uucp (Bakul Shah) (03/23/90)
From: bvs@amdcad.uucp (Bakul Shah) In article <586@longway.TIC.COM> Clive Feather <uunet!relay.EU.net!ixi!clive> writes: > ... >There is a set of changes to the standard being proposed under the title >1003.1b (the copy I have is draft 0.1, May 19, 1989). This adds the test macro >S_ISLNK(m), and the function lstat(). stat() and lstat() differ only in that >stat() never returns information about a symbolic link, whereas lstat() does. >Because you cannot open a symbolic link, fstat() is like stat() here. > >The draft defines two new functions: > > int readlink (char *path, char *buf, int buf_size); > > int symlink (char *target_path, char *symlink_path); > >The functions that operate on links rather than the file pointed to are: > > lstat() readlink() rename() remove() rmdir() symlink() unlink() > >The effects of the following functions form an open issue: > > chown() chmod() link() utime() I hope there is time yet to add/consider another function for completeness sake. int writelink(char *symlink_path, char *new_target_path) or if you prefer, int updatelink(char *symlink_path, char *new_target_path) This replaces the `contents' of a symlink, thereby *not* breaking any hard-links to the symlink. Writelink() is different from rename(), which changes symlink_path, not what it points to. Currently there is no way to simulate this behavior and this makes symlinks a sort of second class objects. -- Bakul Shah bvs@BitBlocks.COM ..!{ames,att,decwrl,pyramid,sun,uunet}!amdcad!light!bvs Volume-Number: Volume 19, Number 22