cjard

New Members
  • Content Count

    3
  • Joined

  • Last visited

About cjard

  • Rank
    New User
  1. If I have a folder "master" that I share on windows server 1, then I enter the "read only secret" on windows server 2 and tick the "Restore modified files to original version" option of the share, why would .conflict files appear in this configuration? Surely what the master server says is what goes, and any attempts to change or introduce new files on server 2 will just see sync overwrite them with versions from the master? note: i'm trying to migrate a mail service by moving all its config files from one machine to the other, the service seems to have created some of the files again (let's say "mailboxes.db") with no data. If stop the mail service on the destination server, and I remove both the mailboxes.conflict.db (made bt btsync from server 1, last update yesterday) and the mailboxes.db (seems to be created 6 days ago when i started syncing, as a fresh empty db by the mail server software), then after a moment mailboxes.conflict.db reappears, but there isn't any mailboxes.db existing for it to conflict with! If I rename mailboxes.conflict.db to mailboxes.db then after a few moments another mailboxes.conflict.db appears. it's like the local sync has come to believe "these files are in conflict, i'll just create a .conflict version". When is the "this file is in a state of conflict" reassessed?
  2. 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?
  3. Downloaded and installed 1.4 beta on a computer that has no mouse, only to find that the app was completely unusable after the EULA had been accepted because the TAB key couldn't be used to give focus to anything.. 1.3 is similarly unusable because the "Standard Setup" vs "I have a Secret" wizard doesn't respond to pressing TAB - focus is locked to "Standard Setup", the tickbox at the bottom of the page doesn't ever get focus to accept the agreement, and thus the other buttons (which cannot be focused) remain greyed out.. Can you guys please re-jig the UI so it uses some standard components/widgets that behave normally (accept focus), or give it some visible keyboard shortcuts or something? I'm all for interfaces that look slick, but not at the expense of usability issues such as this.. :/