Hi Steve
On 8/09/10 8:25 AM, "Stephen Kent" <k...@bbn.com> wrote: > Folks, > > At the IETF meeting in Maastricht I mentioned that we might need to > augment the repository structure doc (that I briefed on Geoff's > behalf) with some sort of lock capability. My concern is that if RP > softwre visits a publication point (file system directory) while the > directory is being modified, the RP software has no easy way to know > that rsync has returned an inconsistent set of records. I agree, there does appear to be an issue here where changes during fetch could cause delays via validation/refresh/validation stages. > > Yes, the manifest will indicate a mismatch in this case, but the > manifest was designed to enable an RP to detect malicious > modification of a directory. If we try to use a manifest to detect > inconsistency due to benign directory maintenance, I fear this will > lead to a lot of complexity. Also, if one downloads signed objects > and later processes them against the manifest (itself a signed > object) detecting an inconsistency may be late in the process, long > after the directory was visited, making it harder (and slower) to > respond. > > I think it would be clearer if we had a separate object dedicated to > this function. The mechanism should be easy to check quickly, > enabling RP software to detect that a directory is being modified, so > that the RP can discard the (changed) files that it is retrieving, > and schedule a revisit to the directory in a little while, when the > directory update is complete. Although I think I would be reluctant to add another object, for the same complexity reasons that exist in the manifest instance and I'm not sure that it will avoid the issues about concurrent modifications as the RP's fetch may run longer than the creation/destruction/validity of the object as well as any update to the repository. This also makes me think about the depth 0, 1, or infinity issues of directory and subdirectories. > > I have no specific proposal for the lock object, or the details of > how RP software interpret it. I'l looking for suggestions, or an > alternative way to address the problem. 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. Cheers Terry _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
