deoren

Members
  • Content Count

    6
  • Joined

  • Last visited

Everything posted by deoren

  1. It does for me, but my purposes may be fairly simple. I primarily backup/mirror loose files kept within the local "sdcard" and Nandroid backups (TWRP, clockworkmod) which are basically tarball archives. My assumption would be that the tarballs keep up with symbolic links and anything UNIX specific. To BitTorrent Sync the tarballs are just regular files. I have root access on both devices where I use the approach, so I'm not really tested with other setups. Does that answer your question?
  2. You can use bind mounts, but I think that requires root access. Here is a short script that I ran at boot via Universal init.d: #!/system/bin/sh# http://www.technohunk.com/2013/02/how-to-execute-a-command-at-boot-android/# Use with Universal init.d# Place at /system/etc/init.d/clockworkmod-mountmkdir -p /clockworkmount -o bind /mnt/shell/emulated/clockworkmod /clockworkThis makes an otherwise hidden directory visible to BitTorrent sync so I can replicate my ClockworkMod Recovery backups on my Nook tablet to peer devices for backup. If you wanted to link in other content you could do something like this: mkdir /BitSyncmkdir /BitSync/clockworkmkdir /BitSync/Downloadsmkdir /BitSync/backupsmount -o bind /mnt/shell/emulated/clockworkmod /BitSync/clockworkmount -o bind /sdcard/Download /BitSync/Downloadmount -o bind /sdcard/backups /BitSync/backupsThere is probably a better way, but that's the approach that based on my current knowledge I would use on an Android device.
  3. RomanZ, Thanks for the reply. In my case I completely removed the content from all peers and created a new Sync Folder on the source system. That system is the one which showed only 1/10th of the total files available in the Windows profile in the Folder view within BitTorrent Sync. Regarding that profile and being logged in, I logged in as the local Administrator account and not the user account tied to the profile I wanted to replicate. This was after a reboot and after applicable file handles should have been released. I can understand that some file handles might be open due to an Anti-Virus app or any sort of file system indexing process, but I would not expect that to result in nearly 30,000 fewer files listed in the client. Regarding the script, it looks pretty handy, but I'll wait to use something like that until BitTorrent Sync matures a little bit and reports the number of files correctly. I'll clear the current log and will enable debug logging on the source system. I'll then provide that log to syncapp@bittorrent.com for further review. Thank you for your time.
  4. Did you ever find a resolution for your issue? Your problem sounds similar to the issue I've noticed with trying to sync a Windows profile folder.
  5. Hi, I looked over the Unofficial BitTorrent Sync FAQs list and found a section that somewhat matches my situation: Reading that gives me the impression that the actual number of files would be listed correctly within the app, but just not transferred for one of the reasons listed. In my case, the number of files is vastly different: Around 3000 listed in the app and around 33,000 actual files Permissions are good as I'm running the app as a local administrator account and I have explicitly reset the Administrators group as having full access and "pushed" permissions down. The source system is a Windows XP Professional (SP3) system and I have rebooted the system to make sure that any locked files for the affected profile (not the local administrator whose account is active) are freed. I've also opened the .SyncIgnore file on the source and a destination system and commented out all default entries (and closed/reopened the app). I even went and found a Windows touch tool that allowed me to reset the last modified time recursively on all files and that only resulted in around 100 more files listed than was previously shown in the Size column (X GB in Y files). During all of this I rebooted the system several times and closed/reopened the client (not just the app window, but the application itself) after each change to test the results. Any tips? I haven't collected the logs and mailed them in yet. I was hoping that maybe this was a known issue with a workaround. If not, I'll gladly collect the logs and mail them in. Thanks.
  6. I understand why putting "0" in the sync_trash_ttl would disable tossing items, but based on the naming (and manual description) wouldn't putting "0" in the folder_rescan_interval stop new items from showing up?