bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] cp: preserve time stamps on symlinks, too


From: Jim Meyering
Subject: Re: [PATCH] cp: preserve time stamps on symlinks, too
Date: Sun, 02 Aug 2009 12:27:16 +0200

Pádraig Brady wrote:
> Jim Meyering wrote:
>> This patch may not be ready for prime time.
>> I wrote it and the test a few days ago, but haven't
>> gone back and looked closely.  There are just too many
>> branches and use cases, and I'm sure I haven't considered
>> all of them.  However, all tests do pass, at least on
>> recent gnu/linux systems.
>>
>> If anyone feels like giving this a try or reviewing it,
>> I'd appreciate any feedback.
>
> Wow, what a hairball of a function :)
> I spent 30 mins looking at it and can't see any issues.

Thanks for looking.
I reviewed it once more and tried to build on solaris 10.
There, it fails to compile because they lack utimensat.
Instead, they have only futimesat, which cannot change
the times of a symlink, since it operates on a file descriptor.

Since there appears to be no syscall like FreeBSD's lutimes that can
operate on symlinks, we can't even simulate utimensat via /proc on
Solaris 10.

This may amount to a show-stopper, because...
it is against principles to have differing semantics
(sometimes preserving symlink mtimes sometimes not)
on different platforms, and adding new diagnostics
to inform (or fail) about every failure seems far too invasive.

Opensolaris does appear to have utimensat, so coreutils
with this patch should build fine there, but we can't
dismiss Solaris 10 just yet.

Actually, the simplest work-around may be adequate:
simply ignore failure when it's due to ENOTSUP.
That appears to be what rsync does.

Next step: *bsd, which have proc, but not utimensat.
At least freebsd6 lacks it.  So we'll need new emulation
code in openat.c.

Portability is a pain.
Hmm... this isn't very important, so providing
a replacement utimensat that always returns ENOTSUP may be fine.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]