Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!longway!std-unix From: std-unix@longway.TIC.COM (Moderator, John S. Quarterman) Newsgroups: comp.std.unix Subject: Re: extending 1003.1 to include sym links Summary: 1003.1 are doing it Message-ID: <586@longway.TIC.COM> Date: 21 Mar 90 07:03:49 GMT References: <580@longway.TIC.COM> Reply-To: Clive Feather Organization: IXI Limited, Cambridge, UK Lines: 37 Approved: jsq@longway.tic.com (Moderator, John S. Quarterman) From: Clive Feather 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