Consider this case when one creates a file with an invalid filename (for
the server) in a directory in the local side.
say: foo/bar/%invalid%.txt
The following would happen:
- in the update for the local parent folder foo/bar/, the md5 is 0
because the mtime has changed
- During the reconcile, we try to send %invalid%, but there will be an
error and nothing will be changed on the server, the etags stay the
same
- We do not do any PROPFIND at the end so we do not fetch the etag
anymore. The md5 is still 0 and will be saved like that in the DB
- Next run, since the etags have not changed on the server, we read
from the DB. But a md5 of 0 in the DB means the folder was removed on
the server. That would remove the local folder (BAD!)
So we load the md5 from the db even if the local mtime change.
That means we need to compare the mtime in the local case rather than
the md5 to see if something has changed.
csync would not update the etag (md5) for directoru in the database if
the etag has changed, but none of the files within that directory
actually changed
Consider this case when one creates a file with an invalid filename (for
the server) in a directory in the local side.
say: foo/bar/%invalid%.txt
The following would happen:
- in the update for the local parent folder foo/bar/, the md5 is 0
because the mtime has changed
- During the reconcile, we try to send %invalid%, but there will be an
error and nothing will be changed on the server, the etags stay the
same
- We do not do any PROPFIND at the end so we do not fetch the etag
anymore. The md5 is still 0 and will be saved like that in the DB
- Next run, since the etags have not changed on the server, we read
from the DB. But a md5 of 0 in the DB means the folder was removed on
the server. That would remove the local folder (BAD!)
So we load the md5 from the db even if the local mtime change.
That means we need to compare the mtime in the local case rather than
the md5 to see if something has changed.
