Rsync - does it really do an *exact* copy?

martin aa martinaa at linuxmail.org
Wed May 31 13:18:03 GMT 2006


> ----- Original Message -----
> From: "Matt McCutchen" <hashproduct+rsync at gmail.com>
> To: "martin aa" <martinaa at linuxmail.org>
> Subject: Re: Rsync - does it really do an *exact* copy?
> Date: Mon, 29 May 2006 15:50:35 -0400
> 
> 
> On Mon, 2006-05-29 at 17:55 +0200, Paul Slootman wrote:
> > On Mon 29 May 2006, martin aa wrote:
> > > > > > I've just been busy with a new system, and I've been copying over the
> > > > root filesystem multiple times with rsync, without any such problems
> > > > whatsoever, so at least for me rsync works just fine for that task.
> > > > Well, that is interesting.  I'm using FC5 and, by the looks 
> > of your domain name, you're using a debian-based distro.  So, I 
> > really can't work out what is happening here.  As I said in my 
> > original post, I can't see how it could be anything other than 
> > rsync doing this, but I just can't see how.  My understanding is 
> > that by using -aH you preserve absolutely everything.  Is there 
> > some type of file that rsync just can't accurately copy?
> >
> > Perhaps extended attributes, if they're used in FC5? If so, I'd expect
> > the FC5 version of rsync to support those (although maybe you need an
> > extra option for that?)  Alternatively, some SE-Linux complications?
> > In other words, something's probably involved that's not "old school"
> > unix.
> 
> If SE-Linux is enabled, there's a very good chance that it is causing
> the problem.  SE-Linux expects each file on the system to carry a
> security context in the extended attribute "security.selinux".  The
> kernel assigns contexts to newly created files automatically based on
> the system's policy.  If a file carries the wrong context, the kernel
> may prevent users, even root, from accessing it.
> 
> I'm guessing that, when you ran rsync, the system was running on the old
> partitions and had the new ones mounted somewhere in /mnt or /media.  If
> you did not ask rsync to preserve extended attributes (-X or --xattrs),
> the files created on the mounted partitions probably got generic "file
> on removable device" contexts, not the contexts that they would need for
> a system to run on them.
> 
> Boot your system once with SE-Linux disabled by passing the argument
> "selinux=0" to the kernel.  If you use Grub, just press the appropriate
> key to "edit the kernel arguments before booting".  If the system then
> lets you log in, SE-Linux was the problem, and you should either disable
> it permanently by putting "selinux=0" in your grub.conf or fix all the
> file contexts by running "restorecon -r /".
> 
> Matt

Fixed!

Thanks very much Paul and Matt - very good advice!

It was SE-Linux that was the culprit as you suggested.  And you were right Matt that the extended attributes were not copied across.

I don't think I would have had this problem if the man page was correct.  With the FC5 distro, the man page for rsync doesn't match the version (which is 2.6.6).  That is, if I 'man rsync' there is no information at all in regards to the -X (--xattrs) option.  (Nor does the man page say anything about the -A (--acls) option.)  However, the usage information (running rsync --help) shows both these options.  A lot of time would have been saved if that inconsistancy hadn't existed - oh well, as they say: "rsync comes with ABSOLUTELY NO WARRANTY" (!)

Also, the man page (and usage info) says for the -a option:
-a, --archive               archive mode; equivalent to -rlptgoD (no -H)

which, IMHO, I think should actually say:
-a, --archive               archive mode; equivalent to -rlptgoD (no -H, -X, -A)

Thanks again for your insightful advice.

Regards, Martin
Ps. What about a supercharged archive option (like -aa) which does -rlptgoDHXA ??


-- 
_______________________________________________
Check out the latest SMS services @ http://www.linuxmail.org
This allows you to send and receive SMS through your mailbox.

Powered by Outblaze


More information about the rsync mailing list