Docs: detecting metadata changes
I just tested our backup system, that is done with rsync. When I changed metadata of file --- for example permissions --- rsync notices change and copies permissions to backup. However, our archiving does not work. So I can roll back to older contents of a file but not to older permissions, owner/group information etc. Several web pages claim that rsync does not detect metadata changes at all. See for example http://www.noah.org/wiki/rsync_notes I think that rsync FAQ or other documentation should cover this. Difference between mtime and ctime might not be that clear to all. Also there could be some note about cp -u, because it is first thing to come in mind if somebody is setting up archiving backups. -- Jori Mäntysalo -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Docs: detecting metadata changes
On 04.02.2014 12:56, Jori Mantysalo wrote: I just tested our backup system, that is done with rsync. When I changed metadata of file --- for example permissions --- rsync notices change and copies permissions to backup. However, our archiving does not work. So I can roll back to older contents of a file but not to older permissions, owner/group information etc. Several web pages claim that rsync does not detect metadata changes at all. See for example http://www.noah.org/wiki/rsync_notes I think that rsync FAQ or other documentation should cover this. Difference between mtime and ctime might not be that clear to all. Also there could be some note about cp -u, because it is first thing to come in mind if somebody is setting up archiving backups. rsync cares about permissions when you tell it to care about permissions. As you didn't provide an example of your commandline (and/or daemon-config) i can only assume that you didn't use the necessary option. The commandline-options -p/--perms is for telling rsync to care about permissions. The common -a/--archive includes it. The other thing: By default rsync does pure permission changes without telling you that it did something (Assuming a singular -v). If you want to see such things, you have to use -i/--itemize-changes. -- Matthias -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Fwd: Bugg when using Extended Attributes flag -X
Hello, I found that using rsync on OS X can give some problems when it comes to Extended Attributes (-X flag). The server I use has Ubuntu with the filesystem XFS and I am trying to backup a OS X system to it. The problem is as far as I understand it that Linux Kernel has a liming on 64k för Extended Attributes and OS X don't have this limit. Some error output. rsync: rsync_xal_set: lsetxattr(/srv/danne/extern2/1000_EXT/2013/2013-03-05/IMG_6872-Edit.tif,user.com.apple.ResourceFork) failed: Argument list too long (7) Error 2 rsync: rsync_xal_set: lsetxattr(/srv/nas/home/apple_bak_rsync/x/Pictures/iPhoto Library/Database/BigBlobs.apdb,user.com.apple.FinderInfo) failed: Operation not permitted (1) Both this errors will go away if removing the -X flag from rsync. What I would like to see is a feature in rsync that checks the destination operation system environment and if it can't handle the size of the EA being transferred then stores the EA information in a separate file. //Sun_Blood -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: List subdirectories only n level deep on the remote server when use the -a option of rsync.
On Sun 02 Feb 2014, Hongyi Zhao wrote: But I've tried the following methodes based on your suggestion and get different results: werner@debian:~$ rsync -a --exclude '/*/*/*/*' rsync://ftp.cn.debian.org/debian | wc -l 1798 werner@debian:~$ rsync -a --exclude '/*/*/*/**' rsync://ftp.cn.debian.org/debian | wc -l 1798 werner@debian:~$ rsync -a --exclude '/*/*/*/***' rsync://ftp.cn.debian.org/debian | wc -l 1631 As you can see, the first two give same results, but the third, i.e., the one you gives, give a different result. Why does this happen? From the manpage: * a trailing dir_name/*** will match both the directory (as if dir_name/ had been specified) and everything in the directory (as if dir_name/** had been specified). This behavior was added in version 2.6.7. Paul -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
[Bug 10357] make check fails for xattr tests
https://bugzilla.samba.org/show_bug.cgi?id=10357 --- Comment #8 from Pavel Šimerda (pavlix) psime...@redhat.com 2014-02-04 21:45:23 UTC --- (In reply to comment #7) With 'fakeroot' package installed, all tests with 3.1.1pre1 on the gentoo box Gentoo pass. Please keep the bug open until I verify it on on other systems as well. I'll supply the information ASAP and will close the bug if it works for me. So, I unfortunately confirmed the bug on a RHEL7 machine with vanilla 3.1.1pre1 as well. Therefore it seems the difference is somewhere in the system environment and not in the version. -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Feature Request: don't sync if it would result in more than NUM deletions.
As a safety feature, I would like to see a feature that would prevent rsync from syncing when the sync, if it were to go ahead, would result in more than a certain number of files being deleted from the destination. A similar feature, --max-delete, does exist, but does not prevent rsync from doing a partial run when --max-delete entries would be exceeded - it simply deletes up to that amount of files. In scheduled scripts, this would result in damage being done a bit at a time at each run, so not really a safety feature and additionally, even if problem caught after only one run, it still means the clone is in an unknown state (at least without processing thousands of log delete entries). A workaround I considered was doing a dry-run first, then only proceeding with the rsync when the dry-run doesn't exit with exit codes 25, but this is extremely inefficient - completely impractical for e.g. syncing large data stores overnight (4Tb in my case). I suspect there would be reasonable demand for and use of this feature by others. -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
