svn commit: r271771 - in head: bin/csh etc/mail lib/libc usr.bin/grep usr.sbin/mtree

[Will Andrews]

On Sat, Sep 20, 2014 at 1:38 AM, Bruce Evans <brde at optusnet.com.au> wrote:
> The log message is confused.  Source files are not being overwritten.
> They are being copied to object directories using cp.  Then if they
> are read-only in the source directory, they are read-only in the object
> directory, even if they are copied without -p so as to clobber their
> timestamps (their mode is still preserved).  Then if the source file's
> mtime is changed, either by actually changing the file or just by
> clobbering its mtime, the copy in the object directory becomes out of
> date.  Then the cp to make it up to date fails because it is read-only.

Yes, this is the more correct way of explaining the issue.  Thanks.

> Many makefiles avoid this problem by using cat instead of cp to copy
> the files.  I prefer using cp -p.  The above fixes the problem for
> a makefile that uses cp (without -p) by adding -f.  This causes the file
> to be unlinked before a new copy is made.  If the object directory is
> in the source tree (most likely since it is the source directory) and
> the source files are read-only, then this would often fail because the
> source directory is also read-only, but then it can't reasonably be
> an object directory.

The problem with 'cp -p' is that it doesn't work either.  Try it
(twice) with a read-only file -- I get EPERM when I try the second
time.  cp -p also doesn't work with NFS targets if the file happens to
have flags.

In the case of .CURDIR == .OBJDIR, the file would satisfy the
dependency and thus not be overwritten with itself.  In any case, this
is about read-only *files* anyway, not read-only directories, since as
you point out, the latter are unusable as object directories.

--Will.