i see the origin pageUI like this.
it will take a long time. i think rename/move should’t take long. so it did “delete” & "add " action, whick i can see in Global Changes list.
i have tried 6 time, every time i move/rename a different file. every time it show one “delete” and one “add”.
It will always show up as delete and add, as that’s the only things handled by the protocol, but it’s optimized internally.
Your original statement was misleading: The screenshot you just sent shows that the file is not synced, it is copied locally. Look at the color of the progressbar and the legend above.
As @AudriusButkevicius pointed out in the post below, the following is simply false - wasn’t aware that Syncthing does move files.
However Syncthing does never move files, only copy and delete as it operates on block level. That’s why you perceive it as slow even though it doesn’t have to be synced.
It does have a shortcut for move (which does not involve copy), the fact that it’s not moving the file and copying bit by bit means that the files are either not the same, or the delete has not arrived, and it’s assembling pieces from files existing in the folder.
Hi,
“If it’s a lot of files, that’s going to happen”
I’m coming with some idea of implementation / correction - because with some DSL bandwidth access (upload : 100KB/s), it makes some move impossible to do without using a portable computer with Syncthing, or an USB HDD, and to manually move the big files into the other destination using car and/or public transports (or letting it synchronize back several days or weeks) (for a file that already was on the remote computer, but just moved and get deleted ! That’s so avoidable !) - sometimes I go find some 4G network with my car and laptop to gain some time and fuel (4G : big upload bandwidth) but it’s too bad to have this kind of mission in order to re-upload something that already was on the other side
If I had to code something that would do differently, it would simply be (on the uploader side) “wait for the analysis to be terminated before committing any change" or "after a file is deleted, re-scan the folder in order to check if it doesn’t appeared somewhere else before committing the deletion” (it can handle the case when the file moved during a folder scan).
The message then contains “file moved” and the remote computer doesn’t delete it. If it’s not that way it works (no “move” message), “file created” could be sent before “file deleted”. Any way, when a new pair connect after some while, “creation” messages should go before “deletion” messages.
At the end of this operation, no moved file can be accidentally deleted and entirely re-uploaded !
Such improvement on the main function of the project would be very appreciated, by me at least, but may be not only - It’s something that is really missing and very problematic with most of the Home DSL internet connections with low upload bandwidth
If you actually read whats happening, file is not being redownloaded, it’s being copied (rather than renamed, as the delete is split into a separate message). I also explained how to work around this.
Thank you for you answer,
Yes I saw your workaroud for this problem - I’m gonna use it personally (even if it’s not as optimal as a simple move, for really big files) - I will also try to teach my co-workers how to do that and try to explain them why
But you should understand that it’s actually not the way people works most of the time, it’s workaround for a bug or at least, a kind of missed functionality of Syncthing
I don’t know what improvements are in the planning but this one would be useful : this is very problematic for DSL connections - as a matter of facts once the folder is synced a huge part of the big uploads we had are moves or renames of existing folders (placed into “finished” for example, or renamed after few days)
Anyway, that’s just a suggestion - I would be very happy if this problem is solved, and while it’s not I will use the workaround and try to explain people how to do so
Bye !
As explained above and visible in the screenshots, there is no transfers happening, it’s reconstructing the file out of locally available data, so your DSL argument is completely moot here.
Yes, there are cases where we will copy+delete and not rename (as seen in this case), but again, that not hitting the network.
And yes, there are cases where transfers will happen (moving files between syncthing folders, at which point it’s a race of whats discovered first) but it’s an exception, not the norm.
I got it!!! The purple color means copy from local disk, the progress-bar speed depend on hard drive performance, not the network bandwidth. Because it did’t touch the network.
I misread signals and think the speed is slow because it redownload through network. My bad…sorry
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
