djsuperstore Posted November 21, 2013 Report Share Posted November 21, 2013 I'm getting the following error in the log. Failed to download filespec - PostDownload: Cannot create a file when that file already exists. Indeed I have checked the files and the copy doesn't match the original. Sync is in read only mode, Quote Link to comment Share on other sites More sharing options...
nzth Posted November 22, 2013 Report Share Posted November 22, 2013 (edited) I'm having this problem too. I didn't notice it occuring before installing 1.2.73, though am unsure when it first began. Deleting the file on the machine recieving the updated file seems to fix it, however it just happens again the next time the file is updated. Here's some pruned stuff from syng.log that may be relevant. There seems to be three copies of the file its having problems with in the same folder, in this case: Default.rdp, Deault.rdp.SyncOld, Default.rdp.SyncTemp.[2013-11-23 08:24:21.218] [SyncFolderNotify] Processing fs event[2013-11-23 08:24:21.218] [SyncFolderNotify] Event: FA_MODIFIED, File: Docs[2013-11-23 08:24:21.218] [SyncFolderNotify] Processing fs event[2013-11-23 08:24:21.218] [SyncFolderNotify] Event: FA_REMOVED, File: Default.rdp.SyncTemp[2013-11-23 08:24:21.218] Torrent \\?\G:\Docs\Documents\Default.rdp status:134 error:<NULL> meta:1 conns:0 io:0[2013-11-23 08:24:21.218] [OnNotifyFileChange] \\?\G:\Docs\Documents\Default.rdp.SyncTemp, source = NULL[2013-11-23 08:24:21.264] TorrentFile: download using patch (diff:32768) Default.rdp[2013-11-23 08:24:21.452] Merge: processing have_pieces message[2013-11-23 08:24:21.452] State sync finished for folder \\?\G:\Docs\Documents[2013-11-23 08:24:22.468] Going to connect to peer 192.168.69.144:14389 for file Default.rdp[2013-11-23 08:24:22.468] Torrent \\?\G:\Docs\Documents\Default.rdp status:137 error:<NULL> meta:1 conns:1 io:0[2013-11-23 08:24:22.624] Extension: ipv4:[*snip*] for '\\?\G:\Docs\Documents\Default.rdp'[2013-11-23 08:24:22.702] [SyncFolderNotify] Processing fs event[2013-11-23 08:24:22.702] [SyncFolderNotify] Event: FA_ADDED, File: Default.rdp.SyncTemp[2013-11-23 08:24:22.702] [OnNotifyFileChange] \\?\G:\Docs\Documents\Default.rdp.SyncTemp, source = NULL[2013-11-23 08:24:22.764] [SyncFolderNotify] Processing fs event[2013-11-23 08:24:22.764] [SyncFolderNotify] Event: FA_MODIFIED, File: Default.rdp.SyncTemp[2013-11-23 08:24:22.764] [OnNotifyFileChange] \\?\G:\Docs\Documents\Default.rdp.SyncTemp, source = NULL[2013-11-23 08:24:22.780] \\?\G:\Docs\Documents\Default.rdp: Piece 0 complete[2013-11-23 08:24:22.780] TorrentFile: failed to rename \\?\G:\Docs\Documents\Default.rdp into .SyncOld - 183[2013-11-23 08:24:22.780] Error: \\?\G:\Docs\Documents\Default.rdp - PostDownload: Cannot create a file when that file already exists.[2013-11-23 08:24:23.296] Torrent \\?\G:\Docs\Documents\Default.rdp status:152 error:PostDownload: Cannot create a file when that file already exists. meta:1 conns:0 io:0[2013-11-23 08:24:23.296] Error downloading file Default.rdp: PostDownload: Cannot create a file when that file already exists.[2013-11-23 08:24:23.296] Force unloading torrent \\?\G:\Docs\Documents\Default.rdp Edited November 22, 2013 by nzth Quote Link to comment Share on other sites More sharing options...
fakeidforsupport Posted November 22, 2013 Report Share Posted November 22, 2013 Had same problem today on one machine. Shutdown and restarted sync on it and that solved the problem. It immediately started downloading the previously undownloaded files. Quote Link to comment Share on other sites More sharing options...
GreatMarko Posted November 22, 2013 Report Share Posted November 22, 2013 Yep, I've seen this same error too on a couple of occasions on 1.2.73 when sharing between full-access devices, so the issue isn't just limited to "read-only" shares. From what I can determine, the files are transferring as .SyncPart, .SyncTemp, or SyncOLD files, but then not being correctly renamed to removed the .SyncPart/.SyncTemp/.SyndOLD. The "PostDownload: Cannot create a file..." error is then thrown and the result is the original file (i.e. the "older" version that should be being updated/replaced) is still present along with a corresponding .SyncPart/.SyncTemp/.SyncOLD file. My "workaround" was to delete any .SyncPart, .SyncTemp, or .SyncOLD files, as well as the original file on the receiving device - this causes Sync to re-transfer the newer/updated file to the device. Quote Link to comment Share on other sites More sharing options...
Zbig Posted November 22, 2013 Report Share Posted November 22, 2013 Same here. To me is looks like some race condition/thread congestion/deadlock/whatever. It seems to pop-up randomly on one of my systems. It happens for some files, seemingly at random, then these same files get processed properly after quitting and re-running the application. Rinse and repeat and it eventually syncs all of the files. Quote Link to comment Share on other sites More sharing options...
nzth Posted November 22, 2013 Report Share Posted November 22, 2013 I'm having no luck with restarting, The only thing that seems to (temporarily) fix it is to manually delete the file on the receiving machine. Though it just happens again the next time the file is updated. Quote Link to comment Share on other sites More sharing options...
ade_m Posted November 22, 2013 Report Share Posted November 22, 2013 I've been seeing this too. Quote Link to comment Share on other sites More sharing options...
JimmyTheSaint Posted November 22, 2013 Report Share Posted November 22, 2013 At first, it looked different to me, so I posted a new problem at http://forum.bittorrent.com/topic/25095-incorrect-postdownload-error/, but apparently what I posted there is the same problem as this thread's. Quote Link to comment Share on other sites More sharing options...
Kai Posted November 23, 2013 Report Share Posted November 23, 2013 The same here. ML OSX and Win7 machines all with BTSync 1.2.73 between full-access folders. Sometimes BitTorrent Sync breaks/corrupts the file. With older versions 1.1.xx did not happen. Quote Link to comment Share on other sites More sharing options...
itsjustme Posted November 26, 2013 Report Share Posted November 26, 2013 We're seeing this issue syncing between OS X 10.8.5 and Win 7 Pro. No issues with Mac-to-Mac syncing. Quote Link to comment Share on other sites More sharing options...
planecrash Posted November 26, 2013 Report Share Posted November 26, 2013 (edited) The same here. ML OSX and Win7 machines all with BTSync 1.2.73 between full-access folders. Sometimes BitTorrent Sync breaks/corrupts the file. With older versions 1.1.xx did not happen. I am also experiencing this issue. I also did not experience this issue before 1.2.73. It is only happening on one of my systems. I tried removing the folder from BTSync, deleting the folder from file system, and then resetting up sync for that folder in a different location. Issue started again almost immediately. The system I am experiencing this on is a Windows Server 2012 virtual machine on windows azure. Maybe I never restarted after upgrading to 1.2.73. Going to do that now. Please help! Edited November 26, 2013 by planecrash Quote Link to comment Share on other sites More sharing options...
GreatMarko Posted November 27, 2013 Report Share Posted November 27, 2013 So just to sum up what everyone's saying - this is only affecting Sync 1.2.73, and is not OS-specific. I suggest if/when you next encounter this issue, that you report it. I'll do the same too, but I only encountered this issue once during my extensive testing, and haven't since been able to recreate again. Quote Link to comment Share on other sites More sharing options...
Kai Posted November 27, 2013 Report Share Posted November 27, 2013 Hi GreatMarko Here we have found this problem between Mac to Mac and Mac to Win, so is not OS-specific, as you said, with every 1.2.xx version. With older versions 1.1.xx did never happen. Almost every day and sometimes Sync corrupts the original file. Thanks we got Backups! We see "PostDownload: hostname not found" and the .SyncPart file is always not renamed. As you suggested we have to manually delete them. It does not matter the file size, happens to less than 1Mb and also to 15Gb VM files. Quote Link to comment Share on other sites More sharing options...
JimmyTheSaint Posted November 28, 2013 Report Share Posted November 28, 2013 This problem keeps happening often enough to be quite aggravating. I can't see a pattern as to when it happens, though I suspect when you update versions on some client(s), it's more likely to occur. I get out of it by finding one client with the most recent version of the file, saving it somewhere, then deleting the original and all its associated sync files from the client where it failed to sync. At that point, the newest version is synced from another computer. This puts me back in a consistent state, but I would have expected deleting all that suff from the "stuck" client to delete the file in all its forms everywhere. Happily, btsync is too smart for that, but I fear that eventually stuff will get clobbered. Quote Link to comment Share on other sites More sharing options...
mrpbdy Posted November 30, 2013 Report Share Posted November 30, 2013 Removing all .SyncOld files gets things back on track without having to remove anything else. Hopefully a future version will detect old .SyncOld files and remove them automatically. http://forum.bittorrent.com/topic/12658-if-you-have-syncapp-issue/?p=73255 Quote Link to comment Share on other sites More sharing options...
djsuperstore Posted November 30, 2013 Author Report Share Posted November 30, 2013 Yes I found the same solution, however randomly the same problem occurs and with different files also. Once deleted I ran WinMerge from http://winmerge.org/ to confirm that the folders are identical. Quote Link to comment Share on other sites More sharing options...
JimmyTheSaint Posted December 1, 2013 Report Share Posted December 1, 2013 Removing all .SyncOld files gets things back on track without having to remove anything else.The problem still occurs with 1.2.82, and removing all .SyncOld files doesn't fix it for me. I've fixed it in the past by deleting all related files, then the actual file synced properly from other clients. If you do it that way, you have to save a copy before risking deleting the file in question, so it's a chore. When I tried deleting just the .SyncOld file, it didn't sync, and then when I removed the file, it got deleted on all clients. So the order in which you fix things matters. Quote Link to comment Share on other sites More sharing options...
planecrash Posted December 2, 2013 Report Share Posted December 2, 2013 The problem still occurs with 1.2.82, and removing all .SyncOld files doesn't fix it for me. I've fixed it in the past by deleting all related files, then the actual file synced properly from other clients. If you it that way, you have to save a copy before risking deleting the file in question, so it's a chore. When I tried deleting just the .SyncOld file, it didn't sync, and then when I removed the file, it got deleted on all clients. So the order in you fix things matters. I agree. mrpbdy's advice does not work for me either. In addition to his advice, as previously stated, I've wiped out the entire folder from sync and the file system. Set up sync again in a different location on the file system, only to have the issue recur shortly after. Actually, resyncing occurred after deleting the syncold file as mrbdy suggested. But the problem isn't that there's not a way to manually fix the issue, but that the issue occurs at all and requires manual intervention. I've updated to 1.2.82 and ensured everything is syncing properly. I'll keep you all updated if the issue occurs again. Quote Link to comment Share on other sites More sharing options...
chiuvas Posted December 2, 2013 Report Share Posted December 2, 2013 I'm still having this with 1.2.82. And deleting *.Sync* files resulted in corrupted file :/ Quote Link to comment Share on other sites More sharing options...
crash893 Posted December 5, 2013 Report Share Posted December 5, 2013 I'm getting it too. I was thinking of writing a script to run every so offten but I'm not sure thats a good idea untill i know why its screwing up Quote Link to comment Share on other sites More sharing options...
Kai Posted December 5, 2013 Report Share Posted December 5, 2013 After a few days of testing, last version 1.2.82 seems to solve the .syncpart problem for us.We will see... Quote Link to comment Share on other sites More sharing options...
foo8ar Posted December 7, 2013 Report Share Posted December 7, 2013 Still is a problem.I'm using a multiple machine setup with OS X (10.8), Win32 and FreeBSD (9.1) all using 1.2.82. It keeps trying over and over again with the PostDownload error message. /f Quote Link to comment Share on other sites More sharing options...
JimmyTheSaint Posted December 8, 2013 Report Share Posted December 8, 2013 I must say, I can't detect any kind of pattern as to when this problem arises, so I can't think of anything to experiment with. For example, I just went a few days with no PostDownload error. About 24 hours ago, I copied a directory tree of about 200 folders (3k total subfolders) containing about 7k files and 1.5GB. I do this every week for backup. This time, I notice one file--buried a few levels deep in a rather random, rarely accessed location--that gets caught in the PostDownload error. Happily, BitTorrent Sync's history leads you directly to it. So far, simply deleting the .old files fixes the condition and allows sync to complete, and it's only ever been one file at a time. My worry is that, when doing a mass copy, that sometime it won't be just one file, but a whole bunch that end up in the PostDownload error condition. I would expect that using the proper file searching utility would make fixing the multiple case almost as easy as the single case, but still. Quote Link to comment Share on other sites More sharing options...
Bejay_Waddell Posted December 17, 2013 Report Share Posted December 17, 2013 I may be able to help with the pattern detection because I have this issue with sixty four files, and I fixed this issue last week when I had seventy of them. This gives me a wide spread to analyse. For me the files are all files that are loaded into memory by the editor and then when saved the old file is overwritten by the new. An overwrite. These files were not held open by their editor while being edited. My guess is that sync is getting confused when a file is overwritten with an identical file (Or at least one very similar) Quote Link to comment Share on other sites More sharing options...
GreatMarko Posted December 17, 2013 Report Share Posted December 17, 2013 Yeah, I concur with @Bejay_Waddell - on the few times I've encountered this it's been with existing files that have just been updated, I've never experienced this issue with "new" files added to a Sync folder. 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.