Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!longway!std-unix From: bvs@amdcad.uucp (Bakul Shah) Newsgroups: comp.std.unix Subject: Re: extending 1003.1 to include sym links Message-ID: <591@longway.TIC.COM> Date: 22 Mar 90 19:17:03 GMT References: <580@longway.TIC.COM> <586@longway.TIC.COM> Sender: std-unix@longway.TIC.COM Reply-To: bvs@amdcad.uucp (Bakul Shah) Organization: Bit Blocks, Inc. Lines: 42 Approved: jsq@longway.tic.com (Moderator, John S. Quarterman) From: bvs@amdcad.uucp (Bakul Shah) In article <586@longway.TIC.COM> Clive Feather 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