Failed to download ***.jpg - CheckOriginalFile: No such file or directory

[flo89]

Hi!

I run the version 2.3.1 under an arm device and get a lot of these errors

Failed to download folder/picture.jpg - CheckOriginalFile: No such file or directory

 

but this file exists on the source machine and on the arm device which raises this error message.

 

I never got this message on one of my other devices(Windows, FreeNAS, same version)

 

What do these errors mean and how can I prevent them?

Edited February 4, 2016 by flo89

[flo89]

just got a simmilar error on the FreeNAS device.

 

Failed to download /folder/xxx.jpg - WriteToDisk: No such file or directory

in the sync UI I see 1 file missing to download, it retrys and retrys, if I delete this file in the filesystem it resyncs it again sucessfully.

[Helen]

flo89,

There is a ticket opened by you with support team. And it seems that you have RO peer? 
 

I'll provide the answer for others as well: 
This means either of two:

1) unable to obtain file info for file, for example if the file itself is busy/locked, or the path to file is incorrect, broken. Then please check permissions, availability and path to the file. 

2) the file got updated, but Sync didn't get a notification about the file update. This shall fix itself during folder rescan or at Sync restarting.

On RO peer keeping "Overwrite any changed files" enabling may also help. 

[seren]

I'm having this issue as well. The server is a FreeNAS box running Btsync 2.3.1. The client is OS X with Btsync 2.3.3.

I pre-populated a folder on the OS X peer with all the files on the NAS, and then added the folder to Btsync using the NAS's read-only key.

The OS X peer started indexing, but as it goes through all the files it keeps spewing CheckOrginialFile errors:
 

Failed to download from desktop/desk/graph/back.bmp - CheckOriginalFile: No such file or directory
Failed to download from desktop/desk/graph/back.jpg - CheckOriginalFile: No such file or directory
Failed to download from desktop/desk/graph/bfrm_lg.gif - CheckOriginalFile: No such file or directory

There are no errors on the RO NAS peer.

If I use an empty folder instead of a pre-populated folder, everything works fine (but takes days).

This is the convoluted procedure that seems to work:

1. Create an empty folder.
2. Start syncing to it with the RO key.
3. Quit Btsync.
4. Seed the folder with files from the external HD, erasing anything that Btsync partially downloaded.
5. Start Btsync again and wait for it to index.

This highlights the difficulty of seeding/pre-populating large shares when using Btsync. It's been a problem since I started using Btsync 2 years ago, and it's still frustrating. It's a common use case for me: keeping large amounts of data in sync and wanting to pre-populate the directories from an external drive so I don't have to wait hours or days for them to initially synchronize over the network.

Maybe I've missed some documentation, but I've never seen a clear explanation of how to do this. Any insight would be much appreciated.

 

 

[Helen]

seren,

Read-Only peers cannot upload anything, as you might know, so if it detects a file that is different from the source, the file is invalidated and not synced. this is now RO works. So, if you pre-populate the folder and then add it as RO share, then who knows what bits of the files might be different. For that case, keep "Overwrite any changed files' enabled, as was mentioned above. 

[seren]

Helen, thanks for your reply.

When I've tried this in the past and not set RO on the pre-populated peer, BTsync has tried to delete and retransfer everything. Now I haven't tested that recently, so maybe that's no longer the case (though the evidence points to it still being an issue). Since the two peers have byte-for-byte identical data and folder structures, the files shouldn't be invalidated or synced. If I'm misunderstanding this, please elucidate me.

[GreatMarko]

Seren,

  Even if the "two peers have byte-for-byte identical data and folder structures" if the file modification times differ, this could cause data to transfer. Are you sure when you "pre-populated" the peer that original file timestamps were maintained?

[seren]

GreatMarko,

That's a good point, and one that I considered. I'm pretty sure they were the same and just tested again to confirm that, on my system at least, copying files retains the created and modified time-stamps.

If I have time, I'll test this process out in a more methodical manner and report back. I suspect the results will be the same, though.

[Helen]

16 hours ago, seren said:

not set RO on the pre-populated peer, BTsync has tried to delete and retransfer everything.

once the RO destination was empty folder, was it trying to delete everything from the RW source and retransfer... where? 

Compare file's chekcsums, and don't forget that if you connect two non-empty directories, Sync has to merge them first, and this is where you can see all those upload-download queues. Or is re-sycning process actually going on in your case?