Vincent Lefevre wrote:
> Bob Proulx wrote:
> > Touch simply open()s the file or calls utime{,s}() on the file.
Note the "or" there. It does one OR the other. It does not do both.
> I don't understand. The utime(2) man page says:
>
> int utime(const char *filename, const struct utimbuf *buf);
> int utimes(const char *filename, const struct timeval times[2]);
>
> i.e. these functions take a filename (string) in argument, not a
> FILE *, not a file descriptor either. So, I don't see why 'touch'
> needs to open the file.
The Unix V7 touch.c code did not have utime available and simply
opened the file, read the first byte, seeked back to the beginning of
the file and wrote that byte back to the file. Because the file was
written the system automatically updated the timestamps. The V7 touch
did not support specifying arbitrary times.
> > 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.)
>
> Yes, this is *exactly* what I mean: 'touch' is part of the few commands
> that operate on the inode,
Ah, here is the basis of the disagreement! There is no lutimes(2)
call and touch cannot use it and cannot operate as you say. It
actually behaves as if it opens the file and writes it, because that
is the way that it originally behaved way-back-in-the-day. The new
presence of utimes(2) has not really changed that but only made it
better. But it is still not an lutimes(2) call.
Files that are touch'd behave the same as if they were written to by
the user. The user has touch'd the file. This is the same as if the
user has written the file. This does not specifically operate on the
inode but actually operates on the real file through any symlinks.
> > > 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.
>
> But it would be more logical to return a non-zero exit status, as
> the 'touch' could not be performed. The -c option means that the
> file is not created (if it doesn't exist), no more.
Sorry but that is not the way that -c was defined.
> For instance, 'touch -c blah/cd' can return the error
No it can't. If it did then it would be a bug.
> touch: setting times of `blah/cd': Permission denied
> though blah/cd doesn't exist. That's inconsistent.
Permission denied is not the same as not creating non-existing files.
If the permission is denied then the file already exists. If you find
otherwise please describe an exact test case to recreate it.
> vin% setopt noclobber
> vin% echo ab >> cd || echo fail
> zsh: no such file or directory: cd
> fail
> vin%
>
> As you can see, a non-zero exit status was returned, because the
> command could not be performed.
How is this related to the topic under discussion? As I recall we
were talking about touch following symlinks.
> ... I can see 3 classes of commands that operate on files/inodes
> (I don't include those that operate on directory entries such as
> 'rm', though their argument are filenames):
> 1. Those that follow symbolic links because it would make no sense
> if they were not: 'chmod' and all the commands that operate on
> the file contents.
Those would be the normal set of commands. awk, cat, grep, sed, etc.
> 2. Those that operate on meta-data and follow symbolic links though
> both the symbolic link and the file have such meta-data (visible
> with 'ls -l'): 'touch'.
But touch operates as if it is modifying the file. I think that is
the root of the problem with regards to your mental model of operation.
> 3. Those that operate on meta-data and do not follow symbolic links
> (by default): 'chown', 'chgrp', 'stat'.
I think in this case you are creating a mental model that does not
exist in the Unix filesystem model. If it worked for you and helped
to understand how things worked then that would be great. But since
it does not and is actively causing problems understanding the Unix
filesystem then I can only suggest taking a deep breath and starting
again.
> For commands of class 1, it is pretty clear, i.e. no need to document
> what they do on symlinks. Now, the problem is: commands of class 2 vs
> commands of class 3. As you can see, 'touch' seems to be the exception.
But touch is not an exception.
> Note: if symbolic links get visible permissions on some system, the
> behavior of 'chmod' on symbolic links should be documented.
But it *is* documented! Here is the documentation from the chmod
manual. Argh!
`chmod' never changes the permissions of symbolic links, since the
`chmod' system call cannot change their permissions. This is not a
problem since the permissions of symbolic links are never used.
However, for each symbolic link listed on the command line, `chmod'
changes the permissions of the pointed-to file. In contrast, `chmod'
ignores symbolic links encountered during recursive directory
traversals.
> > > 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?
>
> Why?
You have taken this discussion full circle. Touch has no need to
document anything special about symlinks since it does not do anything
particular special with regards to symlinks. If it did then I would
agree. Since it does not then it should not.
> > There is no way to update the times on a symlink and therefore no
> > option available in touch to avoid passing through the symlink.
>
> How does the end user know that? I recall that 'ls -l' shows different
> timestamps, so that it is not obvious (contrary to 'chmod').
Sorry but there is no easy road to enlightenment. How does anyone
learn anything? If the world were perfectly simple then I could give
you one simple golden rule and all would be explained after learning
that one thing. But the world is not perfect and the Unix filesystem
is not perfect and the addition of symbolic links to it by BSD created
additional inconsistencies. At some point in the future the behavior
may change and be different fixing some problems and creating others.
This means that there is no simple single rule that you can learn that
will logically describe everything in a consistent way.
> > 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.
>
> Oh, that's confusing. Manuals generally use a different typesetting
> (or markup) to distinguish literals and replaceable text.
The man and info pages have limited markup available. The actual
source uses @var{file} and that is translated by the output process
into the best available markup.
Bob
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
