[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:
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.