Okay, I think we may be operating with slightly different assumptions
about the way things are currently happening, so to start off:
1. I completely agree that processing renames as such would avoid tons
of unneeded data transfer in the case of renames of large files or
directories containing them.
2. I had the understanding due to a comment in another thread that the
only operations that were going across the AFR wire in the case of a
rename was a remove and then a create. If this assumption is wrong,
somebody please correct me.
Back to our discussion, if "healing a directory listing" includes, as
you represent, processing of a list of delete, rename, and add
operations for the directory before its version number is updated,
guaranteeing that a new but unsynchronized file would have a version #
of 0 on the client after synchronizing its parent directory, then I
think your method works.
If, however, the only operations permitted on directory listings is to
present a new list of the current files and directories (basically adds
and removes), then your method breaks down because if a directory
version changes then all children of that directory must be assumed to
be changed. For example, in the second FS state shown below, there is
no way to distinguish which of the three files has changed. Given:
/:2 a/:2 b/:2 c/:4 /A:1
/B:1
/C:1
$ cd /a/b/c
$ rm C
$ echo new content >C
renders:
/:2 a/:2 b/:2 c/:6 /A:1
/B:1
/C:1
My solution solves this last problem (if it, in fact, even exists),
though not the efficient rename issue (if it, in fact, even exists). I
was leaving the transaction journaling issue (basically what you
represent is already being maintained on a per-directory basis), as a
future update which would be easier to integrate once the first problem
was solved.
Regards,
Derek
--
Derek R. Price
Solutions Architect
Ximbiot, LLC <http://ximbiot.com>
Get CVS and Subversion Support from Ximbiot!
v: +1 248.835.1260
f: +1 248.246.1176
