BSD file system

[Dave Mankins]

In article <1344 at accuvax.nwu.edu> rico at math.nwu.edu (Rico Tudor) writes:
>While porting my file archiver from System V to a DECStation 3100, the
>following questions regarding system calls have arisen:
>	(1) How are permissions set on a symbolic link?
>	(2) How are access & modification times set on a symbolic link?

A symbolic link is a way of making another name for a file.  The
permissions of the linked-to file are the permissions used for every name
for the file.  This behavior seems surprising until you realize that it is
just like hard links.  The permissions on the symbolic-link are not used.

Symbolic links are just like hard links only with the ability to span
filesystems (and, sadly, without the ability to know that, when you remove
one name for a file (the target of the symbolic link) there is another name
left dangling without a reference).

>	(3) What purpose is served by taking the group ID of a newly
>		created file from the parent directory, rather than the
>		process?

Under BSD, a process belongs to many groups at one time.  Too bad they
didn't do the same thing for files.

>In Questions (1) and (2), chmod(2) and utimes(2) follow the link, which I
>don't want.  I am handling Question 1 by temporarily altering the process
>"umask", but I don't like it.  The 3100 runs "Ultrix", a BSD variant.

I think you'll find that your handling of question 1 actually has no effect
on what people can do with the files (symlinks) so created.  That is,
denying group-write privilege on the symlink, but not the target, will not
prevent group-members from writing the file.

I am curious, if you're porting this program from System-V, what System-V
function are you trying to emulate using symlinks?

david mankins (dm at think.com)