cjard Posted April 26, 2017 Report Share Posted April 26, 2017 I've been looking into the reasons behind .conflict files and as best I can make out they solely occur when a distant client attempts to sync two files to the conflicting machine that (by way of case sens or symbolic linking) means that one file would overwrite the other.. I don't think this affects me though: Only 2 computers take part in this particular sync, both windows machines The source server is Windows 2003, it has no junction points created (it lacks any tools capable of creating them, downloading and asking sysinternals' Junction tool to scan the entire disk for junctions returns no results) The destination server uses a read-only hash, and "restore modified files" is enabled. "Store deleted copies" is off So, I'm using sync to syncronise two email server data repositories. One day I'll switch the services (IMAP POP SMTP etc) on the source server off, update DNS, activate the services on the dest server and put a TCP redirect from old to new to catch straggling clients whose DNS is stale. Currently the destination server has no mail services running, so nothing is accessing the directory. Most files sync fine, but a few config files (some that change often, some change seldom) are being created as conflicting. If I delete the contents of the config directory on the destination server and wait 5 minutes, the files all reappear, still named with "conflict". I don't really have the luxury of doing anything with the source files (moving them) as this will stop the mail server from working.. Given that I hard delete everything from the destination server, and there's definitely only one sync source, what mechanism is making the dest server think that a file already exists? Is it the source server saying "Here's a file ABC.XML with hash 1234, to be stored in \maildata\config", "Here's another file ABC.XML with hash 5678, to be stored in \maildata\config"? Or is it the destination server thinking ABC.XML already exists (when it doesn't; it's certainly deleted), some broken caching maybe? Also, why don't I get multiple conflict files? i.e. why don't I get abc.xml and abc.conflict.xml on the destination server, one with the source server file content and one with the destination server file content? Quote Link to comment Share on other sites More sharing options...
Helen Posted April 27, 2017 Report Share Posted April 27, 2017 Basically a conflict appears this way, to put it simply: when Sync asks system to write given file into a given directory, the directory is checked, if system detects that this path belongs to a physically different file (from system's POV, each file has a unique ID in the system), a conflict is created, and once we had a case when disk controllers got broken and files' ID were mixed up causing Sync to produce a number of conflict. So if neither case described in the article seems applicable, please send the debug logs from both machines to support, they'll check. Thanks. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.