Re: keep 2 dirs in sync
On Sat, Jul 2, 2011 at 7:32 PM, Mark Constable ma...@renta.net wrote: Would anyone know of any project written in C/C++ based directly on rsync, and maybe Git? The rsync resources page mentions dsync, which is (IIRC) a perl script wrapper around rsync. ..wayne.. -- 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: non-efficient sparse file copying with rsync
The question is whether it is possible to copy sparse files as sparse, but to preserve the original file size? By file size I mean the size, that a file actually occupies on file system as reported by du --block-size=1 FILE. The apparent size is always the same. If supported by your platform, also try: ls -l -s This may be related to the scanning block size rsync uses to determine if sparseness exists, or to write such a file. Maybe, I'm not quite sure of my thinking on this, I'm usually wrong. However, I do know there is a 'bug' filed regarding a large performance lag when copying sparse files with rsync. Just search bugzilla for 'sparse'. Since you're copying big files, it's something to be aware of until further characterized or fixed. -- 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 8284] New: hfs-compression.diff patch incorrectly expands relative directory
https://bugzilla.samba.org/show_bug.cgi?id=8284 Summary: hfs-compression.diff patch incorrectly expands relative directory Product: rsync Version: 3.0.8 Platform: x64 OS/Version: Mac OS X Status: NEW Severity: normal Priority: P5 Component: core AssignedTo: way...@samba.org ReportedBy: rutleco...@gmail.com QAContact: rsync...@samba.org There is a bug when using a relative path for the destination with the hfs-compression.diff patch and --hfs-compression option. (Note that this bug is not present with the --protect-decmpfs option) The Destination: $HOME/Desktop/Untitledfolder2 works as expected, however if, from my Home Directory I use Desktop/Untitledfolder2, the relative path Desktop/Untitledfolder2 is incorrectly expanded to /Users/Tony/Desktop/Untitledfolder2/Desktop/Untitledfolder2 -- /usr/local/bin/rsync -aNHAXv --hfs-compression --fileflags --force-change --delete Desktop/Untitledfolder1/ Desktop/Untitledfolder2 sending incremental file list rsync: statfs /Users/Tony/Desktop/Untitledfolder2/Desktop/Untitledfolder2 failed: No such file or directory (2) rsync error: errors selecting input/output files, dirs (code 3) at main.c(514) [Receiver=3.0.8] rsync: connection unexpectedly closed (9 bytes received so far) [sender] rsync error: error in rsync protocol data stream (code 12) at io.c(601) [sender=3.0.8] -- 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
Brandysnap -- a new rsync-based snapshot management script
Brandysnap is an rsync-based script with a difference. Unlike dirvish, it does not assign importance to snapshots when they are created. All snapshots are created equal, and then they are managed so that the required number of old snapshots is maintained. Unlike rsnapshot, brandysnap does not get its snapshots out of sync if runs are missed, and it is very easy to configure. The link between brandysnap and cron is very simple: just make sure brandysnap is run often enough to create the first level of snapshots. There is no need for separate runs to rotate the snapshot names at the required intervals. Defining which snapshots to keep is simple and intuitive. For example 4d7,7w3,4m11,3y means 'keep 4 snapshots a day for the last 7 days, 7 a week for the 3 weeks before that, then 4 a month for 11 months, then 3 a year forever'. This example is referred to in the explanations below. Such specifications can be as simple or as complex as you like. Brandysnap is flexible. It can be ultra-cautious, refusing to delete old snapshots unless there are enough to completely fill the requested schedule. Or it can be more relaxed, and apply the rules more simply. The periods 'day', 'week', 'month', etc. can be aligned on real calendar periods, or they can be considered as simple spans of time working backwards from 'now'. Brandysnap is effectively stateless: it does not keep any sort of list or database of information about previous runs. It uses the existing snapshots as the basis for deciding what needs to be done. The snapshots it creates are simple directories, which can be accessed without any special tools. Brandysnap is a Perl script designed to run on Linux. If there is demand, I hope to make it work on other operating systems too. It uses rsync (http://rsync.samba.org/) to do all the hard work, including the network and authentication stuff. Most of the cleverness in brandysnap is in deciding which snapshots to keep. As time passes, existing snapshots move into the realm of later specs, which require fewer snapshots to be kept. For example, after a week of keeping 4 snapshots a day, only 7 snapshots out of the existing 28 may still be required. Brandysnap chooses 7 that are spread out across the week to give the most useful set for future recovery. But, and this is the important bit, if runs have been missed for any reason, brandysnap will skip over incomplete periods. For example, if the destination is an external USB drive and someone forgot to plug it in, there will be snapshots missing. Brandysnap does not assume that a '4d7' spec has been completed after 7 days: it only does so when it has found 7 days each with at least 4 snapshots. Only then does it start looking for weeks with at least 7 snapshots. If you don't intend to create snapshots at weekends, specify something like 4d5,7w3,4m11,3y and brandysnap will automatically skip over the weekend days. There are options to fine-tune the way brandysnap behaves. The output includes an analysis of the existing snapshots and the way snapshots have been chosen to be kept or deleted. At present (3 July 2011), brandysnap is still being developed and should be considered 'experimental'. Do not use it for anything important (yet). Brandysnap can be downloaded from GitHub at https://github.com/StarsoftAnalysis/brandysnap where you can follow its development and read more details. Hopefully it will prove useful. I look forward to hearing comments and ideas. cheers Chris -- Chris Denniscgden...@btinternet.com Fordingbridge, Hampshire, UK -- 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: inefficient: --checksum calculation shouldn't be done for new files
Carlos Carvalho wrote: When --checksum is used they're calculated in both ends to see if the file should be transfered. This is of course not necessary if the file doesn't exist in the destination. However, the checksum is still calculated by the sender, which is often a very large overhead. Would it be possible to avoid it? Doesn't the receiver use the checksum to verify it received the file with no errors? -- Jamie -- 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: inefficient: --checksum calculation shouldn't be done for new files
Jamie Lokier (ja...@shareable.org) wrote on 4 July 2011 00:00: Carlos Carvalho wrote: When --checksum is used they're calculated in both ends to see if the file should be transfered. This is of course not necessary if the file doesn't exist in the destination. However, the checksum is still calculated by the sender, which is often a very large overhead. Would it be possible to avoid it? Doesn't the receiver use the checksum to verify it received the file with no errors? Yes, but this always happens, not only with -c. That checksum is calculated during the download and has no overhead. The one with -c is done before, just to decide whether to download. -- 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: Brandysnap -- a new rsync-based snapshot management script
Hi Chris, https://github.com/StarsoftAnalysis/brandysnap I am involved with the LBackup project. Would you be okay with a link being generated to the Brandyon github page from the LBackup alternatives http://www.lbackup.org/alternatives page? Depending upon the license you release Brandysnap under, perhaps in the future Brandysnap functionality could be incorporated into the LBackup project? Sounds like a good project. Thank you for posting the link and explanation. Keep in touch. Henri - This email is protected by LBackup, an open source backup solution. http://www.lbackup.org -- 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
