Hi I rearranged all my Photo folder on one side : I moved all my ./YYYYMM [DD[-DD]] Comment dirs to ./YYYY/YYYYMM [DD[-DD]] Comment. Now st does the job, but he is transfering all pictures through the network (huge amount). I thought he would just do the same on the other side (move). I think I already saw this (displaying “Copying from elsewhere”). What do I miss please ?
It depends, in some cases it will move in some cases it will retransfer, it all depends on the order things are discovered. Best bet is to usually copy, let it appear on the other side and deletw
Thanks man, I thought it was something like this.
This is however very annoying and we should handle it better. The reason it’s done this way now is to minimize the wait between the scan detecting a change, and the other end acting on it, so we might send up the deletes way before the additions.
Don’t worry, st is yet a great soft. Maybe a workaround that would work or help to mitigate sometimes would be to scan the .stversions if exists therein something fresh. [EDIT] oooops : maybe you do it yet (this is the origin of copying from elsewhere status ?)
Bye
Copy from elsewhere means copied from another folder. You could add .stversions as an unshared folder to syncthing, and syncthing would then reuse data from there. It doesn’t look at versions itself (yet I don’t see why it shouldn’t do that).
1 Like
Maybe because it would be over burden to maintain a (special?) index or additionnal entries for .stversions ?
It shouldn’t be part of the index as too many things depend on this, but yeah some separate minimal index that doesn’t track versions or anything, just gives you blocks available and where to find them.
2 Likes
I suggested using blocks from stversions a while back, so I’d like this too.
The workaround “add parent folder incl. stversions - but do not share it” works great. In my case it e.g. helps with large outlook files over slow lines where sometimes Syncthing moves the old file to stversions before transferring the changes which results in a complete and not partial transfer.
1 Like
Would all available .stversions folders be used to populate a single-for-all-SharedFolders “some separate minimal index” Audrius is talking about ? At first sight this seems desirable. I mean there would be a single minimal index whose blocks inside could be used to rebuild a file in a different Folder than original. Maybe this is already the genaral case, I don’t know. Although, this doesn’t address the case when there is not even a minimal Trash Style .stfolder and deletes are proceeded before all. Okay guys, you’re all great devs and I’m confident you choosed the less worse tradeoff according to the variety of usage cases. Bye
Note that in the normal case, Syncthing scans for additions and processes those first, then scans for deletes. So renames will be handled correctly then. The corner cases are when you rearrange things during a scan, or possibly with inotify.
Adding the .stversions as an unshared folder probably won’t help that much with those corner cases, unless you already had an old version lying around that can be reused more or less as is…
To be honest, I think this is more todo with inotify now having checked the code.
I can’t fully parse that.
I think…
“Having checked the code, I now think this issue is caused by the interaction between Syncthing and inotify, rather than it being an issue with Syncthing alone”
1 Like
I can’t rank your opinions, guys. The only thing I can say is that it happened between 2 ubuntu 14.04.5 on which syncthing-inotify is installed but I did nothing to configure st to use inotify, and ps ax|grep inot won’t show anything. And as Jakob suggests, I first moved a big subdir whole content to his parent, and a bunch of seconds latter I did the same on other subdirs. Whatever I only noticied this behaviour after the second move so I can’t say when it began. I don’t know if that matters or not as I don’t know the underlyings but other things I can say is I did this remotely with nemo (sftp), with different methods (cut+paste and drag’n drop, but I can’t remember which one first).
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.