seren

Members
  • Posts

    8
  • Joined

  • Last visited

Recent Profile Visitors

195 profile views

seren's Achievements

New User

New User (1/3)

  1. 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.
  2. 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.
  3. 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: Create an empty folder. Start syncing to it with the RO key. Quit Btsync. Seed the folder with files from the external HD, erasing anything that Btsync partially downloaded. 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.
  4. This is good to know. This behavior confused me for a while since I assumed that BTsync was restarting the transfer each time.
  5. I've had this issue in the past as well, so if you figure out the cause, please post an update.
  6. Actually, an even simpler version of this question is: how do you begin syncing two identical folders without transferring the contents? Is this even possible since the timestamps of when the folders were added to BTSync won't be the same? Thanks.
  7. Is there a way to sync two folders that already have almost identical contents without BTSync transferring everything? I have two computers with 200gb directories that have slowly gotten out of sync over time. I'd like to put them into a BTSynced folder and have them transfer just the changes. From experimentation though, it seems that if I try this, the clients try to transfer the entire contents of their own copy to the remote computer. Is there a way to let the client generate all the hashs for the the files (which are named the same) and then allow them to sync just the files that need it? Thanks a lot!
  8. I love to hear a reason for this as well. I'm seeing duplicate files being transferred as well.