Hot answers tagged

3

If you use an absolute path in a filter (include/exclude), it's interpreted starting from the root of the synchronization. You aren't excluding a directory in the source, or a excluding a directory in the destination, you're excluding a directory in the tree to synchronize. Thus: rsync -av --delete --progress --exclude "/folder4/mytestfolder1" /source/ ...


3

This worked well for me: rsync -vrt --size-only /src /dest The --size-only command compares files only based on size, which was largely unchanged for me. The -t copies over the timestamps.


3

Simply feed it a list of everything you DO want counted using --files0-from find -type f -print0 | du --files0-from=-


2

You can usefully add the -i option to rsync to make it show you why it wants to copy the file again. For example, you might see .f...po.... somefilename which means the remote file has different permissions and owner. One solution is to use --size-only to only compare the sizes of files, but obviously this might cause some changed files not to be sent. ...


2

According to the man page on rsync: "...Blank lines in FILE and lines starting with ’;’ or ’#’ are ignored..." I just ran a quick test and indeed # and ; lines are ignored.


2

SSHFS is convenient, but it doesn't mesh well with rsync or more generally with synchronization tools. The biggest problem is that SSHFS largely kills rsync's performance optimizations. In particular, for medium to large files, when rsync sees that a file has been modified, it calculates checksums on parts of the file on each side in order to transfer only ...


2

To answer your main question: yes there are differences. With sshfs there is an existing connection to allow access to remote files over a secure channel and with rsync over ssh, that secure channel is set up to talk to a remote rsync instance. To answer your secondary question: The rsync over ssh will be faster for most, if not all instances, because the ...


2

There might be a limit on 32 bit versions of these applications, especially older versions not compiled with "large file support". Those problems were not a result of packets being dropped, but on writing (and/or reading) the files at the appropriate size. Back in 1995 there were similar problems with tar under Irix not support files > 2Gb. So make sure you ...


2

You can do this with find and touch. cd destination find -depth -exec touch -r /path/to/source/{} {} \; The -depth option arranges for directories' times to be set after their contents have been set. This assumes that your find interpolates {} when it's a substring of an argument. If it doesn't, invoke a shell: find -depth -exec sh -c 'for x; do touch -r ...


1

This problem is best solved at the rotation stage, not at the copy-and-archive stage. If you change the log rotation to date the files rather than give them sequential numbers, then the rsync archival doesn't need any logic to do the Right Thing™. Assuming you are already using logrotate for rotation, then this can be done with the dateext option. But if ...


1

ext4 uses POSIX ACLs (when they are explicitly enabled via the acl mount option). ZFS uses NFSv4 ACLs (at least on FreeBSD). As the rsync man page states: -A, --acls The source and destination systems must have compatible ACL entries for this option to work properly. Without the -A option, the transfer works without any problems.


1

What you are doing there is at least 'complicated'. As far is i understood, you connect to one server, and tell it to sync to another server. For ease of use, you may specify port and user to use in the local ssh configuration for a particular host. for instance, if you add the following lines to the file ~/.ssh/config (/home/username2/.ssh/config) on the ...


1

When a filesystem provides compression it is usually intended to be transparent, so that there should be no difference between the original file and a compressed version, apart from some meta-data such as the actual number of physical blocks used. This would seem to be the case with Linux NTFS-3g. By default rsync only compares timestamps and sizes of files ...


1

If you have GNU find, you can make it print the file sizes. find /source ! -type d -printf '%P %s\n' Sort the output to get deterministic output. If the filenames contain newlines, it's possible to get the same sorted output for different arrangements, but that's not going to happen unless deliberately engineered. comm -3 <(find /source ! -type d ...


1

In --dry-run mode, rsync determines which files need to be transferred but doesn't actually transfer their data - 'cuz there's no use to do that, naturally. This implies it doesn't perform delta matching - because it's a part of data transfer logic. The reason for the numbers reflecting that is... well... that the code shows actual statistics, not some ...


1

I've seen this when 64bit libraries are installed on 32bit kernels and vice versa.


1

I think I can improve on the answer given by EightBitTony. ssh -t user@target 'sudo cat /source/file' > output && chmod +x output When more than one file is involved, I find pax much easier to use than rsync, not matter how often rsync is "simplified" for me. ssh -t user@target 'cd /src && pax -w ./' | pax -r HTH.


1

Generic FUSE options 1) I noticed allow_other wasn't set on the ntfs-3g filesystem mount. The default for FUSE is not to allow access by other users. mhddfs is a FUSE filesystem and so is ntfs-3g (but see next section). 2) When you use allow_other, you also want to consider permissions checking. The default for FUSE is not to check permissions. So just ...



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