On 10/14/05, Ariz C. Jacinto <[EMAIL PROTECTED]> wrote: > here's what i did before. i created a script on the source to check what > has changed since <specify time> and store it in a log file. then i used > that log file on the destination as a reference for rsync or scp. that way, > sync will start only after the last successful file transfer and not all > over again whenever the link failed.
Yeah, I've already got that. I md5 at the source and download the md5 first. then i md5 at the dest and compare. if they're different then i rsync. the issue is that with rsync, it's necessary to get all the differences in one run. if the run fails, the temporary file (with the matches found and differences resolved) is deleted. so the next time i rsync, i need to find all the matches again and resolve all the differences again. --partial is worse (i thought it was better, like --continue with wget). this is OK. i can deal with this for now. i just thought, though, that i might be able to incrementally continue the partial run. i can see that there might be problems with detecting if either of the src or dest had already changed (if yes, temporary file would have to be thrown away). i just thought of a lossless system that handles temporary incremental upload failure better though. bittorrent! but i don't think i can use it (there are complications if the previous day's upload did not complete and then the upload file is re-created at the source and the torrrent changed. i know that bittorrent will losslessly copy the file, but if the file has changed, does bittorrent know enough to go back and look at previous chunks to see if those chunks might have been invalidated? On 10/14/05, Holden Hao <[EMAIL PROTECTED]> wrote: > I am not sure if it can do what you are asking for but rdiff-backup may > be worth considering. > > http://www.nongnu.org/rdiff-backup/ thanks, i'll look at that. On 10/14/05, Regino Angeles <[EMAIL PROTECTED]> wrote: > You might want to also look at tsync here: > http://sourceforge.net/projects/tsyncd/ > http://tsyncd.sourceforge.net/ > It's one of the entries for Google Summer of Code. and that too :-). actually, rsync is good enough for now. perhaps i'm just overly optimizing :-). tiger -- Gerald Timothy Quimpo http://bopolissimus.blogspot.com [EMAIL PROTECTED] [EMAIL PROTECTED] Public Key: "gpg --keyserver pgp.mit.edu --recv-keys 672F4C78" Everybody who learns concurrency thinks they understand it, ends up finding mysterious races they thought weren't possible, and discovers that they didn't actually understand it yet after all. http://www.gotw.ca/publications/concurrency-ddj.htm _________________________________________________ Philippine Linux Users' Group (PLUG) Mailing List [email protected] (#PLUG @ irc.free.net.ph) Read the Guidelines: http://linux.org.ph/lists Searchable Archives: http://archives.free.net.ph
