Revised flags patch

Steven Hartland killing at multiplay.co.uk
Fri Feb 29 02:07:14 GMT 2008


Attached is a slightly different patch which doesn't attempt chflags
to every file, instead it catches the error case in robust_rename
and only then calls chflags(to, 0)

Hope this helps.
    
    Regards
    Steve

----- Original Message ----- 
From: "Rolf Grossmann" <rg at progtech.net>


> Wayne Davison wrote:
> 
>> Your patch calls chflags(file,0) on every file/dir that is going to be
>> removed or renamed.  Does that slow things down at all?
> 
> I didn't do any benchmark, but it doesn't appear that bad to me. It's 
> one extra syscall per unlink/rename, but I guess the time spent on i/o 
> is negligable because of cache hits. The cost of a chflags call is 
> probably about the same as a chmod call.
> 
>> My current flags patch tries to only call chflags() on the files that
>> need it, but it that code is only active if the user is preserving
>> flags, so the forceful chflags()  call may be a better choice, assuming
>> that things aren't significantly slowed down by that.
> 
> For me, the limiting factor is usually network bandwidth. One extra 
> system call per changed/removed file doesn't make much difference. If 
> there is a benchmark you'd like me to try, I'll try to make time for it.
> 
>> That change for every rename seems a little more doubtful, as it seems
>> like it would always turn off all chflags on renamed files when the
>> --fileflags option isn't specified.
> 
> It is only removing the flags from the file that is about to be 
> removed. Of course, if the file has changed and you're not using 
> --fileflags, you're losing the flags settings for that file, just as if 
> it had not existed in the first place. I believe that is just what 
> happens for the mode if you didn't use -p(*), only that if you're not 
> explicitly removing the flags, you couldn't even rename the file 
> (removing the old one). So I'm only trying to do the same thing as in 
> the remove case.
> 
> (*) actually I just tried and for some reason I'm wrong there, but it 


================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 

In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to postmaster at multiplay.co.uk.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: util.c.patch
Type: application/octet-stream
Size: 275 bytes
Desc: not available
Url : http://lists.samba.org/archive/rsync/attachments/20080229/c1e7ab97/util.c.obj


More information about the rsync mailing list