Re: use lutimens

[Jim Meyering]

Eric Blake wrote:

> According to Eric Blake on 10/9/2009 10:13 AM:
>> Eric Blake <ebb9 <at> byu.net> writes:
>>
>>> This patch is pending my utimensat work on gnulib, but looks pretty slick;
>>> replacing a #if and 12 lines of code with just 1 (modulo the testsuite 
>>> tweak).
>>
>> Next cool patch, also pending on my gnulib utimensat changes.  Again, a net
>> reduction in code size, plus the added benefit of fewer syscalls for 'touch 
>> -a'
>> in the case where native utimensat works.
>
> Now that I've pushed the gnulib patches for utimens, I've put this series
> on the next branch.  OK to merge onto the master branch?
>
> Hmm, I had to push a merge commit to get the next branch updated.  The
> 'non-fast forward' rejection rule for master makes sense, but for the
> 'next' branch, should we relax it to allow rebasing without merge commits?

If you want to adjust the script, you're welcome to.
Please base any changes on this:

    
http://git.et.redhat.com/?p=ovirt-server.git;a=blob_plain;f=git-hook/update;hb=refs/heads/vcs-admin

Please be careful not to merge anything else from next
onto master.  In particular, I deliberately omitted the two
src/README-* files.

I've considered removing that branch altogether.
Then we can recreate it if/when someone would find that useful.

> Eric Blake (3):
>       build: update gnulib submodule to latest, for utimens improvements
>       copy: allow symlink timestamp preservation on more systems
>       touch: optimize use of utimens

Those look fine.  Thanks!
I compared the performance of your modified touch
on a tmpfs file system on a system running rawhide,
creating 100,000 empty files (names 1..100,000), and found
no significant difference when running touch with no options.