djsuperstore

Failed to download PostDownload: Cannot create a file when that file already exists.

Recommended Posts

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,

Share this post


Link to post
Share on other sites

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 by nzth

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 by planecrash

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.