On Sep 8, 2010, at 4:09 AM, Tim Bruijnzeels wrote: >> It sounds like system hackery, but I feel more comfortable in looking >> towards recommendations about how the directory structure is laid down, >> given that rsync is file based and not block based, and after a repository >> is constructed then new file-lists and transfers (for a client) can be >> directed at the latest repository version. Existing rsync processes would >> need to stay within the state of the repository as it was when they were >> started. >> >> Making this a server issue then removes all RP decisions except for >> freshness. >> > > I don't know how to make this work. We do not want to re-implement or > modify rsync(d) so I don't see a way to make client 'sessions' sticky to > a previous state of the repository.
I agree. Requiring modifications or re-implementation of rsyncd is a non-starter in my opinion. However, I read Terry's message as using directory structure to avoid inconsistent states. -andy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
