Hot answers tagged

5

It doesn't delete 4.txt because you are running the rsync command with *, i.e. on the individual source files. Hence, rsync doesn't even consider 4.txt (or the containing directory). Instead, run it on the directory that contains the sources, by changing the * to . Then, rsync can look at the directory as a whole as see what is missing. rsync ...


4

You can use the option --inplace This option changes how rsync transfers a file when its data needs to be updated: instead of the default method of creating a new copy of the file and moving it into place when it is complete, rsync instead writes the updated data directly to the destination file. so ...


1

I like roaima's answer, but the paths are the same in both examples, obscuring which is which. We've established that the following doesn't work: rsync -vuar host1:/host1/path host2:/host2/path But this does (I omitted the explicit bind_address of localhost from the -R option since that's the default): ssh -R 50000:host2:22 host1 'rsync -e "ssh -p ...


1

Do both use the same filesystem? Different filesystems may have different blocksizes so the filesize may be different.


1

Rsync "handles" it by ignoring it. Does that count? Not really... Any changes that get made after rsync copies that portion of the file are lost and not copied. This can mean that different parts of the same file contain data from different points in time. As you suspected, this can be a problem. A workaround I often use on linux (saw your tag) is to ...


1

For backups and real-time synchronization I use glusterfs. Is a very friendly and robust sync & backup package. See more about glusterfs in here.


1

man rsync: If DIR is a relative path, it is relative to the destination directory. You need: rsync -av --dry-run --itemize-changes --compare-dest="$PWD"/test test2/ result/


1

Always try to see if there's already a similar discussion before posting the question. With rsync, all exclude (or include) paths beginning with / are are anchored to the root of transfer. The root of transfer in this case is /share. Use relative path, instead of absolute path and it should work. For further reference, rsync exclude directory not working


1

Never mind: I've found the solution. An app called M3Unify is able to produce playlists and also export the music within the exported playlists. What makes this app different is that it can also rename the files it exports using tag substitution patterns, and can export the files as subfolders, with specific instructions detailing how the files are put in ...


1

When rsync believes it's accessing both source and destination on the same host it does not use its incremental transfer. Instead, it simply copies the entire file. This is the situation in your case. As a result, your second command is copying the file.so~new across your ssh fuse link to the local host, and then immediately copying it back again. Is there ...


1

You could try osync which is designed for exactly this task. I once set up a complex sequence of rsync commands to do the job, but I now use osync. https://github.com/deajan/osync It uses rsync internally, so it should be suitable for any situation where you could use rsync.


1

rsync is the wrong tool for this task, for exactly the reasons that you have encountered. Instead, consider using unison: unison A/ B/ The first time you run this it will identify files that are uniquely in A, and those that are uniquely in B. It will also flag those that are in both places and ask you to identify which is to be overwritten. The next ...



Only top voted, non community-wiki answers of a minimum length are eligible