Vincent Lefevre wrote:
> Bob Proulx wrote:
> > Symlinks create a fundamental operating interface between all
> > programs and the filesystem. They permeate everything that
> > operates on files in a fundamental way. Because they are a very
> > low level interface I don't believe it is possible nor appropriate
> > to note how symlinks affect everything everywhere. The best that
> > can be done is to learn how they affect the filesystem interface
> > and apply that model to all applications that operate on the
> > filesystem.
> >
> > The touch command follows symlinks because generally everything
> > follows symlinks. The commands that do not follow symlinks are the
> > exceptions to that rule.
>
> I'd say this is the opposite for commands that operate on meta-data
> (such as 'touch').
I wanted to trim my quote but I was not sure to what part you were
referring to as being the opposite. I did not understand the meaning
of your statement. Sorry.
Touch simply open()s the file or calls utime{,s}() on the file. The
underlying filesystem then follows the symlink as expected. At least
as I expect it to do anyway. :-)
A symlink can never be an open file. That may help to understand part
of the operating model. Any operation that operates on an open file
descriptor won't be operating on the symlink. By getting to the open
file it will have already passed through the symlink and on to the
target.
> > The rm command is not an exception here because rm operates on
> > symbolic links normally.
>
> It is an exception as it doesn't follow the symbolic links.
But in the case of removing file arguments there is no meaning to
following a symlink. The symlink itself is the file argument and it
is removed. Since rm is really performing a directory operation the
directory either includes the file argument and it is removed from the
directory or it does not and an error occurs.
On another level different from opening files to access the file
contents many filesystem commands are directory level commands. They
either add to or remove from the directory. The rm command is one of
those commands. It removes entries from the directory. Since the
file is never opened the value of the symlink is not used.
> > The ls command is an exception and where it handles symlinks
> > specially is documented.
>
> The stat command (from the coreutils) is also an exception.
Okay, you got me on stat(1). But it is a new addition to coreutils.
Previously it was a standalone command. If it is not documented
appropriately for use with symlinks then that should certainly be
improved. However looking at the documentation now it looks to be
adequate. I don't like the wording personally and this will motivate
me to submit an update.
> Ditto for chown and chgrp. I think that most commands that operate
> on meta-data are exceptions!
Yes. So? Other commands are the majority such as cat, grep, sed,
cut, paste, join, and so on. The number of commands that operate on
the inode are a smaller set. I think this means that we are in
agreement here. (Not sure though.)
Recently, in the grand scheme of Unix time, symlinks were added and it
has taken a while for command to catch up by adding options to operate
on the symlink rather than the symlink target. These require
operating system support such as lstat(2) and lchown(2).
> Note: chmod is a bit special because symlinks don't have file
> permissions.
Well, BSD symlinks do not have modes anyway. SysV does have modes but
they are cosmetic only.
> Also touch and chmod are different from other file
> operations that follow the symlinks in the sense that they don't
> return an error if the file doesn't exist:
But for different reasons.
> vin:~> ln -s file link
This stores the string value "file" into the value of the file "link".
If you look at the size of the resulting file you will see that it is
four characters long. Other values would create different sized
symlinks. The value is stored in the symlink and will be used by the
filesystem later if file access calls need to resolve through it.
There is no validation that the target name value stored there exists.
It can't because it does not need to exist when the symlink is
created. It might exist in the future. Or it might never exist. The
file resolution will be handled by the filesystem at the time access
is attempted.
Since the symlink was created successfully the command returns a
successful exit code. If the symlink cannot be created such as due to
insufficient permissions in the directory then a failing exit code
will be returned.
> vin:~> touch -c link
This calls utimes(2) on link, which returns ENOENT (No such file or
directory), indicating that the file does not exist. Because the -c
option was given the file is not created if it does not exist and a
successful exit code is returned. If the -c had not been given then
touch would have opened link for writing and created the file. If it
was successful in creating the file it would have exited no error. If
that operation had failed such as due to insufficient permission then
it would have returned a failure.
> vin:~> chmod 644 link
That does seem to be incorrect. It can't succeed and so to me seems
like it should fail. But I have not looked at the history. I will
investigate this one.
> vin:~> cat link
> cat: link: No such file or directory
The open(2) fails, is reported, and a error exit code is returned.
> Isn't that confusing?
The chmod handling of dangling symlinks is confusing and I think
deserves a closer look as to why it is doing what it is doing. All
else follows normally and seems perfectly reasonable to me. Except
for the chmod case above don't you agree?
> > Because 'touch' does not do anything special with regards to symbolic
> > links I do not think it needs any exceptions listed for them. That
> > is, if touch mentioned symlinks then every command should mention
> > symlinks and that would be too much.
>
> Only commands that operate on meta-data (i.e. not the file contents[*])
> are concerned. I don't think that would be too much.
Agreed. But that would mean that touch would not need to mention
symlinks. Right? There is no way to update the times on a symlink
and therefore no option available in touch to avoid passing through
the symlink.
> [*] It is implicit that symlinks are followed to get/create/modify
> file contents. But meta-data are part of the inode and a symlink has
> its own inode.
Full agreement.
> > Actually FILE in the above refers to the use of FILE as a command line
> > argument to the touch command as noted in the synopsis. It could say
> > the following not using FILE and also be correct:
> >
> > touch [OPTION]... FOO...
> >
> > Any FOO that does not exist is created empty.
> >
> > A FOO of `-' causes `touch' to change the times of the file
> > associated with standard output.
>
> But again, the term "FOO" would be used with two different meanings.
No. It is not. We are still out of sync somewhere here. FOO means
the literal three characters F, O, O, which appear on the command
synopsis line as a program argument. That could say XYZZY or anything
there. Whatever is there is the argument that will be operated on by
the command. There is only one meaning that I can see for this and it
means the program argument as depicted in the synopsis line.
> > I could suggest the following:
> >
> > touch [OPTION]... FILE...
> >
> > Any FILE argument that does not exist is created empty.
> >
> > A FILE argument string of `-' is handled specially and causes
> > `touch' to change the times of the file associated with standard output.
>
> OK.
Sounds good. Jim was in agreement and so I will submit a patch for
this change.
Bob
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
