Revised flags patch

Rolf Grossmann rg at
Sat Feb 16 02:03:59 GMT 2008

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 
does happen for the owner without -o (running as root, of course).

Bye, Rolf

More information about the rsync mailing list