Patrick O'Callaghan wrote:
On Sat, 2009-12-05 at 11:02 -0800, Daniel B. Thurman wrote:
Patrick O'Callaghan wrote:
On Fri, 2009-12-04 at 16:13 -0800, Daniel B. Thurman wrote:
The problem I have specifically with rsync (or tar, or cp) is that
it does not save ACLs, file attributes too well, and so on that I
gave up using it. Perhaps the problem in this case is not to use
the -a option but to use the manual options to save everything
about the files that you can.
Specifically:
rsync manual:
-a, --archive archive mode; equals -rlptgoD (no -H,-A,-X)
-H, --hard-links preserve hard links
-A, --acls preserve ACLs (implies -p)
-X, --xattrs preserve extended attributes
Do you mean that you've tried these (particularly -A and -X) and they
don't work? If so, have you filed a bug report?
I am not certain that it's a bug per-se, it's just that there are
cases, or so it seems, where it is not clear how to deal with
the issue on my part. For example, hard links (-H). How are
hard links handled on one drive to be copied over to another
and is it guaranteed to work? I could not get my mind around
this one so I did not want to take a chance.
Well, you could try it. Since you're copying to a fresh drive anyway,
there's no harm in doing it and checking the result.
Hard links are an easy case in fact, and trivial to check. Create file A
and hard link B to it. Rsync A and B to a different filesystem, using
the -H option. Use "ls -i" on the copied files to see that they both
have the same inode. That's all a hard link is.
As for ACLs (-A),
what exactly is being handled here and does this work for ALL
Oses concerned - do they follow the same "standard"?
WTF? Of course not. I thought we were talking about Linux here. In fact
there's been no indication in this thread of anything to the contrary.
There is no "standard" for this stuff across OSes (I suppose Posix might
be considered a standard but I'd be very careful about relying on it).
We're doing low-level system maintenance here. Don't expect anything to
be portable.
I am thinking
about Vista in particular, so I did not want to experiment on this
one either.
I wouldn't dream of doing this on a non-Unix system.
As for extended attributes (-X), I have no clue exactly
what this is. I guess I have to someday take the time to do more
research before messing around with these rsync options. This is a
particular reason why I am using dd/rescue & resizing - it works sans
Vista, which I have yet to try.
Again, rsync is a *Unix* utility, designed for *Unix* filesystems
*only*. If you'd said at the beginning that you wanted to move a Vista
partition we could have saved ourselves a lot of time.
poc
I was being general. The same issue applies to linux when it comes
to rsync. If one relies on rsync to keep all the file atttibutes with -a
option, there are surprises as I mentioned. I threw in Vista just to
make a point that rsync does not work with Vista (or Xp), as you
already know. It pays to know what these rsync options do and
what OSes rsync works with, again which you already know, but
it is written here for those that don't - me included. I learned the
hard way by testing it all out so that I know what works and what
doesn't. I found that rsync does copy the data on Xp or Vista, but
sans the file attributes. At least with a failing drive most of the data
was "saved" when in a hurry. It sure is fast.
Getting back on topic - it is dd/rescue that works for (some) OSes and
so far it does. I discovered that it definitely works with XP so as long
as the partition copied from source to destination is the same partition#
- otherwise, one is forced to 'fixBoot' because somehow the partition
data (boot.ini) and the partition "MBR" are not "in sync". Vista on the
other hand does not work even if dd'ing source to destination, with the
same partition#s.
I am fighting a battle on another system trying to get XP & Vista's boot
partition to work where the partition to partition copy are not the same,
local or to different drives.
FWIW,
Dan
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
