🚀 go-pugleaf

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