Dealing With '.conflict.' Folders

[wimbit]

I have reassigned the passwords on a number of machines. Some got the Encrypted Read-Only password. Others got the regular full password.

 

Now, I am finding '.Conflict.' as folders all over the place. Also, some even '.Conflict.Conflict.' folders.

 

Thinking I might have to write a script to deal with them. Apart from file times, I assume they must all be the same since nothing else changed.

 

Anybody else have this? How are you dealing with it?

 

 

[wimbit]

I am bumping this up because I have never seen this before and also I have searched and not found anything in the FAQ or pdf manual referring to this issue. Bump!

[RomanZ]

wimbit,

 

.conflict gets added to the file when couple of files / folders attempt to be copied to a single file / folder. For example - same filename with a different letter case on Unix would be 2 different files, while on Windows it is the same file.

 

I guess you won't be able to send debug logs as you revert to 1.2. Could you please share the scenario (as detailed as possible) what were you doing so we can try to reproduce it in our lab?

 

Thanks!

[wimbit]

Sure.

 

I have 6 machines, 23 folders with own secret (each main folder has own secret to avoid security exposure and make things complicated:) )

 

EROS = Encyrpted read only secret

 

1 NAS Debian, PowerPC (EROS everything since NAS is not encrypted)

1 PC x86 (EROS most folders,some full secret)

1 PC x64(Full secret all 23 folders)

2 laptops x64 (Full secret all 23 folders)

1 Android (5 folders, full secret) ** Had no problems here and still on 1.3. Also, no '.Conflict' folders here.

 

Ok. So .. everything was using full-secret, fully synced.

 

1) I updated NAS by (a) turned of btsync service ( deleted all folders © installed 1.3 btsync (d) turned back on. Nothing on machine, no secrets yet.

 

2) Updated 1 laptop to 1.3. Removed all folders syncing and re-added folders with new secrets with 'D' prefix.

 

3) Update other laptop to 1.3. Did same (2), removed all folders syncing, and re-added with 'D' prefix secrets.

 

4) with x64 PC, just changed the secrets to 'D' prefix without removing and re-adding sync folders.

 

.. by this time I was noticing '.Conflict' folders appearing.

 

5) Eventually had x32 PC and NAS on with EROS secrets and syncing. No crashes on PowerPC, only x64 and x32 PC and laptops.

 

Proceeded to get all updated and eventually stable. But a lot of crashes along the way.

 

I assume this had nothing to do with filename case as postulated, since the sync already existed and all filenames were as original. All I can think is that the conversion to the new secret, and keeping the folders on each machine, something got buggy with filetimes or the way sync think 'which was first'.

 

Hope that helps. Now, off to write a groovy script to amalgamate a bazzillion '.Conflict' folders and clean things up  Oh, yeah, have someone document the '.Conflict' folder thing, pleaseeee!

[RomanZ]

wimbit,

 

Thanks for the details. 

 

 

 

Oh, yeah, have someone document the '.Conflict' folder thing, pleaseeee!

We'll do.

[firecat53]

I also got bit by this bug. For me the '*.Conflict.Conflict' or '*.Conflict1' '*.Conflict2' folders were empty, so I had to find and delete those, then rename the '*.Conflict' folders to remove the '.Conflict' extension. It seemed to be _mostly_ all directories that were affected, not files. I used (Linux):

find . -type d -name '*.Conflict.Conflict' -exec rm -r '{}' \;

find . -type d -name '*.Conflict' -exec rename 's/\.Conflict$//' '{}' \;

CAUTION: notice the 'rm -r' in the first command....make sure those directories are empty first!! Run the commands without the '-exec' part first just to make sure you're finding the correct directories.

 

The 'rename' command might be called 'perl-rename' depending on your system.

 

Scott

[RomanZ]

firecat53,

 

Can you share your scenario? What were you doing when you get .conflict files / folders appearing?

[firecat53]

I upgraded btsync on my laptop (Arch) to 1.3.67. The server (Ubuntu 12.04) was still running 1.2.92 (latest previous version). It may have been my fault, because I was also testing btsync inside a Docker container and doing a lot of starts and stops of the daemon on both laptop and server. Unfortunately I can't tell you the exact sequence of events because the problems occurred in a couple of really big (104GB and 37GB) archive folders for music and pictures that I don't look at all that often. Perhaps I suspended my laptop while it was still trying to process all the data...I'm not really sure. But...that's what backups are for! :-) Sorry I can't be of more help...but I'll definitely be more aware next time of a major upgrade and provide better feedback to you.

 

Scott

[RomanZ]

Thank you Scott. I think that I might try to catch it in the debug logs, if the .conflict folders still appear for you. Can you collect debug logs?

[firecat53]

Yep, I'll turn that on for now. File 'debug.txt' with one line 'FFFF' in either .sync or wherever btsync.conf is located, correct?

 

Scott

[RomanZ]

in either .sync folder - or in your "storage" folder if you configure sync with config file.

[wimbit]

".conflict gets added to the file when couple of files / folders attempt to be copied to a single file / folder. For example - same filename with a different letter case on Unix would be 2 different files, while on Windows it is the same file."

 

This is not the case with my circumstance. The machines were previously in-sync using v1.2.87 prior to the update to 1.3 and prior to any folder secret reassignments. The problem started with Windows before Unix was added to the equation. So, has to be something other than a filename issue.

[noiime]

I have a similar problem with some of our R/O peers, except it is happening on files not folder.

All of them are on windows 2008 and windows 8/8.1.

BTS rev 1.3.67

 

- The problem began shortly after upgrading from rev.1.2.91 to 1.3.67

- No files has been add or modified since almost a month.

- All the affected share were working fine before the upgrade.

- Strangely, R/W share don't seems to be affected by this issue

 

It was propagating between peers so I had to shut them down before it mess up all the shares/peers.

(Over 80 peers for these share)

 

Here's what I was able to grab in the log before I had to shut them down

 

[2014-03-27 16:39:00] TorrentFile: Failed to create empty suffix for file "\\?\T:\artofst_en.Conflict.mpg" - 5
[2014-03-27 16:39:00] SyncFilesController: failed to load torrent for file "\\?\T:\artofst_en.Conflict.mpg"
[2014-03-27 16:39:00] TorrentFile: Failed to create empty suffix for file "\\?\T:\augusto_en.Conflict.mpg" - 5
[2014-03-27 16:39:00] SyncFilesController: failed to load torrent for file "\\?\T:\augusto_en.Conflict.mpg

 

I've tried to restart some of the affected peers and enabled the debug log but the issue isn't happening for now.

*** I suspect that I didn't start one of the peers that was generating the behavior

[RomanZ]

Nolime,

 

Could you share your logs so we can see all the bunch of messages there?

[Fukkei]

noiime,

 

could you please check that "T:\" drive is added to the sync as "T:\" and not as "t:\" ? If not - this may be a root of the problem, when path of sync folder contains letters in wrong case.

[noiime]

Hi Romanz,

The debug log has been sent, ticket number (#9071)

 

Fukkei,

I confirm that the T:\ is really T:\

 

Tx

[firstzerg]

I also had a problem with ".Conflict" folders on windows. (Sync 1.3.67)

The problem was that on two machines, there were two same folders but in names used different cases (uppercase and lowercase).

"Data" and "data" in windows is identical filenames, but BittorentSync not understand this.

Edited March 29, 2014 by firstzerg

[RomanZ]

 

 

"Data" and "data" in windows is identical filenames, but BittorentSync not understand this.

 

They are identical only on Windows. All other platforms treat it as different filenames, while BTSync is cross-platform tool.

 

@firstzerg, please wait for the next build where issue is likely to be resolved.

[visnumber]

Umlaute in a Folder name create .Conflict in BTS 1.3.77 on Macs. There is clearly a bug, I had it in many folders. If the folder name contains an "Umlaut" like ä ü ö etc. then the folder will be marked as a conflict-Folder and duplicated but ONLY if it is the root folder of a sync folder. It does not happen in deeper levels. You have to create a new folder without umlaut, move the contents of both old folders (.Conflict and without .Confict) to the new one, that works. Not a pleasant bug in german speaking countries and many more....

[RomanZ]

visnumber,

 

Thanks for reporting. We've managed to reproduce issue in lab and will fix it in one of future releases.

[JSommer]

Sorry but the problem with .Conflict is still existing - updated to 1.3.87 - all Folder with german "Umlaute" like "ä ö ü..." were duplicated in .Conflict Folders - here´s a screenshot, only some minutes old (synching between three Macs 10.9.2 using BTsync 1.3.87)

 

[RomanZ]

JSommer - please see my response in other topic

[DrBrynzo]

I ran into this today: I have one master system where I store all my photos (~72GB). This is a Debian Linux box. I have 3 other systems with read-only keys to that folder, one Windows 7 and two OS X 10.9.

 

I upgraded all to 1.3 last night and found several folders with IMG_2000.Conflict.jpg files on the Windows machine. After reading through this thread and some others I figured out it was due to the case-sensitivity issue. Some editor or utility I used saved the files as *.jpg instead of *.JPG so I had "dupes". This was easy to fix (or so I thought) by eliminating the duplicate files on the source (Linux) machine.

 

The problem was that even though I removed the duplicates on the source and eventually on every one of the systems (while BTSync was stopped) they kept reappearing on the Windows machine no matter what when I would start BTSync back up again. It's like they were still somehow in the database even though they no longer existed on the filesystems of any of the machines.

 

The way I ultimately fixed it was to remove the sync folder on the Windows machine, delete the *.Conflict.* files, and re-add the sync folder. This somehow blew them away, probably by cleaning out whatever queue or database still had the files in it.

 

Now that I know what was wrong it makes sense but the fact that I wasn't able to fix it without removing and re-adding the sync folder isn't optimal. Even on a very fast machine, it took around a half hour for the databases to rebuild and start syncing again. This problem would be greatly exaggerated if this were hundreds of gigabytes or more of files. 

 

It would be really nice if this could be handled in some kind of informative message in the clients when you have differing case handling. If I hadn't found this thread I'd probably still be banging my head against the wall as just renaming the files isn't very communicative. For someone that understands case sensitivity and runs multiple operating systems it's arguably discoverable but for people with a Linux-based NAS or something on their network who don't crack open the filesystem it could be a real pickle.

 

By the way, please keep it up. BTSync is a utility I've wanted for YEARS. I cobbled together similar things using rsync and other utilities but BTSync is what I was always trying to get to.

[zkyevolved]

I've been getting this bug as of lately far too often. My current set up is:

My PC (Windows 64 bit)

Few laptop computers (all 64 bit)

 

And a server, Raspberry Pi, that keeps everything synced together.  

 

I'm not sure how to update the software for BTSync on my Raspberry Pi, but I imagine it's working fine as it says on BT Sync page (Up to date). What happens is, all of a sudden, the software freezes (BT Sync on Windows) and I can't open it. I open task manager and it says it's using 20-30% of my HDD usage, but very little to no network usage. It creates conflict after conflict. In fact I see Conflict1.conflict.conflict.etc.etc,  and it just gets longer and longer. Sometimes I even see Conflict2.conflict.conflict.conflict.conflict. It gets so long that Windows tells me I can't delete them! So what I have to do is go into my RPi and delete it within there as it's more flexible than Windows, then that change syncs over to the other computers. And so I force close BTSync on my windows machines and then reload, and then the nightmare continues! I have to redo this every time on every machine to get rid of the conflicts. I turn them all on, and they all keep generating conflicts. Until they're all deleted from all computers at the same time.

 

What do you guys think? 

 

Kind regards.