[Top][All Lists]

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

Re: use lutimens

From: Jim Meyering
Subject: Re: use lutimens
Date: Sat, 10 Oct 2009 21:35:48 +0200

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:


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.

reply via email to

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