pjank

Members
  • Posts

    10
  • Joined

  • Last visited

Everything posted by pjank

  1. As it turns out, I've had logging enabled on one of the target peers :-o Completely forgot about that And it is there - exactly 1998 times :-) I've just sent the log file to the support.
  2. I didn't know that. Thank you for the clarification, Helen. I did take a closer look and... that's actually not exactly true. It is kinda interesting though. After few hours, when all the files have synced eventually, it looks like this: 1) Renamed folder A: 1221 files, ~400MB - the Archive on one target computer contains 998 of the same files (~340MB), and on another target machine - *exactly* the same 998 files as well. 2) Renamed folder B: 2644 files, ~1GB - the Archive (again, both target computers) contains exactly 1998 of the same files (~770MB). In all cases that were the older files in both folders (first on the list when sorted by name or date) that were left in Archive, only the last (latest) 223 / 646 (folder A / B ) files were apparently restored and didn't have to be downloaded again. The fact that both remote machines behaved in exactly the same way makes me think it's not random. There has to be some logic behind this And that x998 number? That's suspicious.... Anyway, I will try to track it down with a debug log enabled next time I need to do similar rename. And until then... maybe those details above give you any hints, or raise new questions about what is going on? Thanks, PJ
  3. Hi, This was in my eyes one of the biggest advantages of BTSync over some other syncing solutions. There have been some problems from time to time, but I thought they were all fixed by now. Unfortunately, I've just experienced (twice!) an unwanted behaviour in what I would call a simple folder rename. I could swear this was working 1/2 years ago in identical situations, but now - seems broken. :/ I'm talking about detecting a folder rename. That's a folder inside a "standard Sync folder", not the sync folder itself. A folder containing hundreds/thousands of files. What I would expect: - Sync just *instantly* replicates the same folder rename operation on all other machines. What actually happened: - Sync on the originating machine actually does detect there was a rename ("History" shows all the events like "Renamed file <oldfolder>/<filename> to <newfolder>/<filename>"). That's half success :-O - Sync on all the other machines unfortunately still treats this as a REMOVE + ADD operation, causing unnecessary TRANSFER of gigabytes of data, wasted time and space (moves the "old" folder to Archive). Very bad! :-( Do I ask for too much? :-/ Configuration: - source machine: Linux, others: Linux / Windows - version on all: 2.2.5 BTW. If only the "Archive" contained all the files with the ORIGINAL timestamps - I could maybe just stop the btsync process, restore folder from the backup, rename it manually and then let btsync reindex it again (hopefully without transferring the whole files over the network). But it does not - all the archived files' modified time-stamps are updated to the date/time of this archiving event! WHY!?
  4. Funny thing - I've just noticed the "share" button is suddenly working for me now I'm not sure if it's FF version related or not, but it's 34.0.5 at the moment.
  5. I don't think the window size matters. Even full-screen on a fullhd display (1920x1080) doesn't make a difference. But there you go. Attached is a screenshot taken while the mouse was hovering over the options button in one of the rows. As you can see - that button works fine. Only the 'Share' one is missing.
  6. Same here - no share button, in any folder. BTSync 1.4.103, Firefox 33.1.1 on Linux.
  7. Hello again, I'm surprised nobody confirmed nor denied this bug. Was my previous post too long/complicated? Let me simplify... I've recently switched to Linux on my laptop and can still reproduce the problem (so it wasn't Windows-specific), also on a different - much smaller folder. All clients upgraded to 1.4.103. Steps to reproduce: 1) Create "test" directory in a shared folder. 2) Edit .sync/IgnoreList, add a line: "/test" (linux) or "\test" (windows) 3) Add a file "test/1.txt" on a remote computer... It's not propagated to the local computer - good - "ignore" works so far... 4) Restart the local btsync client... The file "test/1.txt" suddenly shows up - WRONG - this was not supposed to happen! Today I've noticed that adding another change in that "test" directory on the remote computer (like creating next file, e.g. "test/2.txt") is not propagated at this moment. Only after a next restart of the local client. So I assume the bug exists only during the application startup (initial connecting to peers, maybe indexing folder?)... and only until the IgnoreList file is modified (see my first post). After that - everything works fine. Also - it affects only remote changes. Local updates to the "ignored" folder are always ignored as they should be. Greetings, PJ
  8. +1 If nothing else, I think for many of us it would make much more sense to display the folders in alphabetical order (based on the Name) instead of the order in which the folders were added (like it is right now). How about just a simple switch for that in the configuration?
  9. Hi! Among others, I have a folder (about 70GB, thousands of files, about a dozen subfolders in the root folder and hundreds more underneath) synced between few computers. Most of them are Windows (1.4.93), one with Linux (1.4.99). On one Windows laptop I need just a small subset of that folder, so... based on [http://sync-help.bittorrent.com/customer/portal/articles/1673122-ignoring-files-in-sync-ignorelist-] I've set it up to exclude few subfolders, similar to this: \200? \2010 \2011 \2012 \2013 \2014\2014-01* ... \others And this kinda works... if updating the file while btsync is running. But once I restart Sync, it starts to download *everything*. I've tried it for many times: - shut down Sync - delete all unwanted subfolders - launch Sync again - few seconds "loading", connecting to peers etc.. few more secs later *all* the other subfolders show up again (empty so far)... few more seconds later - it starts "Receiving" and filling up the folders with files I don't need. - open up IgnoreList in notepad, hit "Save" (no change, just saving the file again) - suddenly "Receiving" stops, all is well again... until I need to reboot the laptop for example. I've tried different formats for IgnoreList, like this: 200?\* 2010\* ... 2014\2014-01* others\* No change. I've also tried changing backslash to forward slash, or using both (each line duplicated with both: windows or linux directory separator). That doesn't help either. But this simple one: 200? 2010 ... 2014-01* others This one WORKS! ALMOST :-) The problem is - it's not exactly, what I need. I only want to ignore e.g. "others" root folder, not an "others" subfolder anywhere deeper in the structure, nor an "others" file somewhere inside. I would really prefer to have it work the way it's described in the manual - all the time, including at application startup. BTW. The logs (even debug) don't show anything interesting about parsing the IgnoreList file. Except the moment, when it detects a file update and logs "updated ignore list". Thanks for listening, PJ