AzaK

Members
  • Posts

    6
  • Joined

  • Last visited

Everything posted by AzaK

  1. Thanks very much for the detailed response piotrnik. I'll try your method specifically and see if I have some success. I've since found another show-stopper w.r.t. alternate streams and the fact that the Windows client of BTSync treats extended attributes (They are named 'filename:streamname' ) like regular files and so when my HFS driver software on my WIndows destination machine sees them it treats them like regular HFS filenames where ':' is a valid character.
  2. Hi Romanz, thanks very much for the explanation. Paragon implementing it that way makes sense so it's a properly compliant implementation. What would be good then, is for BTSync to know about the filesystems that are in play and utilise the correct behaviour. I assume that if the destination was running on OSX, then BTSync would use an appropriate method for alternate streams and things would work? Maybe there's a feature idea there. To handle accessing streams differently if the destination filesystem does not adhere to the ":stream" format. That would require some other way to access alternate streams on Windows and I'm not sure there is one. I really, really wanted to use BTSync but this is sort of buggering me up a bit. If I went and made sure my filenames were NTFS compatible, would all the extended attributes sync and restore correctly? Thanks
  3. I have just started using Sync between a Mac and a Windows machine (HFS+ on the Windows machine via Paragon Software's implementation) and my extended attributes are ending up in the same directory as the source file, but with an extension ':com.apple.FinderInfo' for instance. It's definitely not being put into the alt streams, or back into the file on the HFS filesystem.
  4. Sorry for adding another reply, I can't seem to edit my post, but in the test above, I was using a Read\Write folder. I did another test today at work and if I add the folder on the destination as Read Only, then it shows up as having no files (Even though there are files copied there) and when I then start up Sync on the source, everything is copied again. I think read only folders should still index and include their existing files in the test for de-synchronised files.
  5. Hi, thanks for the reply. I just tried your suggestion and these are the steps I took and this is what happened: I closed Sync on both machines. Copied the source directory to destination machine. Deleted the SyncID file on the destination machine. I left the .SyncIgnore and .SyncArchive file/folder Ran Sync on the source machine, folder was indexed. Ran Sync on destination and added the folder Indexing flashed up quickly. Folder showed as 0 files and 0 bytes (There were lots of files in the folder) The Data up/down was showing bytes transferring, but the transfer window was empty....at first. After a few seconds, transfers started and it looks like they are all 'somepath\com.apple.FinderInfo' files although I can't be sure there weren't other sneaking in there. The History on the destination says "Finished syncing file XXX" and those XXX's are the names of the files in the folder, not just the com.apple.FinderInfo files.
  6. Can I do the copy after the folders have been set up on BTSync on the source? I have a large number of folders I have just set up and I don't want to have to remove them and start again. Could I just delete all the .Sync files (Except the SyncID) in the source folder (and destination folder where some have been copied) and it'll work? Additionally, copying an already added folder to another disk, deleting all the .Sync files and adding it to BTSync on the destination machine seems to resync all the files if it's set up as read only (What I need). Thanks