Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I've got this scenario: dir1 /home/arek/, dir2 /mnt/home/arek/ (mounted with sshfs).

When I issue: rsync -avz /mnt/home/arek /home/arek, I get /home/arek/arek with the whole content. Some directories are ok in /home, some not. There are no links (neither hard nor symbolic).

Does anybody know what is going on and how to protect myself ?

share|improve this question

migrated from stackoverflow.com Mar 26 '11 at 2:11

This question came from our site for professional and enthusiast programmers.

2 Answers 2

up vote 5 down vote accepted

rsync(1) is picky about the trailing slash. Try this:

rsync -avz /mnt/home/arek/ /home/arek

See the manpage for all the details.

Update

If one of the paths is mounted via sshfs, I suggest using rsync(1) differently:

rsync -avzP -e ssh username@remotesystem:/home/arek/ /home/arek

(The -e ssh might be redundant at this point; rsync(1) used to default to rsh!)

The -P asks for partial file transfers to be restarted (very helpful on network links that might die) and shows progress (which is helpful over network links, since they are frequently slower than drive-to-drive copies).

Furthermore, rsync(1) is very clever about doing hashing checks on both endpoints when invoked this way -- disk to CPU bandwidth is much better than disk to ssh to network to ssh to wonky filesystem driver bandwidth -- so you will be transferring much less data across the network.

Consider: if you append a single byte to every file, rsync(1) over sshfs will be forced to transfer the contents of every single file from the source to the destination. rsync(1) over ssh(1) will instead start an rsync(1) on the remote endpoint and do the hashing computations on both machines as necessary, and will probably only transfer the last 8192 bytes of every file.

share|improve this answer
    
yes, it works now ok, but only when I issue rsync from / directory. any lower - does not work –  tdi Mar 26 '11 at 8:54
    
@tdi, hrm, are you sure you're giving absolute paths to both source and desination? I've never experienced that behavior before, and couldn't understand the implementation decisions that would make it behave that poorly. –  sarnold Mar 26 '11 at 8:59
    
@sarnold ofc, I give absolute paths. Maybe it is sshfs weird issue. Ill check it later with and w/o –  tdi Mar 26 '11 at 9:36
    
@tdi, I updated my answer with the knowledge that one of the hosts is remote; rsync(1) can be used much more efficiently than pretending source and destination are local. –  sarnold Mar 26 '11 at 9:46
    
@sarnold, thanks, I am ofc aware of that, It was just a migration, developers needed to access old server as a direcotry. you know developers, they do not like to learn much :) –  tdi Mar 26 '11 at 9:56

It's copying the directory /mnt/home/arek into /home/arek, when what you want is for it to copy the contents of /mnt/home/arek. You can get this behaviour by adding a trailing slash to the source directory name: rsync -avz /mnt/home/arek/ /home/arek. Yes, this is a bit strange. It's documented in the rsync manpage, under the heading "USAGE", but it's not explained very clearly there.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.