home *** CD-ROM | disk | FTP | other *** search
- 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
-
-