I know there are similar topics but I think this issue should be solved on the syncthing’s side. Here’s the log:
Feb 20 15:05:46 leaseweb-new syncthing[1014]: [NKCV4] 15:05:46 INFO: Puller (folder dina-dropbox, file "Вспоминайте.. Обсуждение на LiveInternet - Российский Сервис Онлайн-Дневников_files/rMdMpGS2GLyh1cQuWKjaz7Szf5ZRaoKsgKlLvEFgV0Mc4Wkbney_pz4MdiIuWf0FwloL_2tA2z6ALPwwB_SGHk4z7DeRZimZYsfWrXsZei7zwayFN8rhLBOYC2gRo3Un7zAamg0dX0TuPSeivjl-tZH6SI7r0di98P-O0lRU5Q99cvxFYUcrOQGlxP66aCg-kAN95adYwqxi2loZ8bGW108T-Nvtzp9mTT_n4D5JjnVAOPmtK6EpTLIPfYK3VHT"): delete file: rename /home/user/Dropbox/Вспоминайте.. Обсуждение на LiveInternet - Российский Сервис Онлайн-Дневников_files/rMdMpGS2GLyh1cQuWKjaz7Szf5ZRaoKsgKlLvEFgV0Mc4Wkbney_pz4MdiIuWf0FwloL_2tA2z6ALPwwB_SGHk4z7DeRZimZYsfWrXsZei7zwayFN8rhLBOYC2gRo3Un7zAamg0dX0TuPSeivjl-tZH6SI7r0di98P-O0lRU5Q99cvxFYUcrOQGlxP66aCg-kAN95adYwqxi2loZ8bGW108T-Nvtzp9mTT_n4D5JjnVAOPmtK6EpTLIPfYK3VHT /home/user/Dropbox/.stversions/Вспоминайте.. Обсуждение на LiveInternet - Российский Сервис Онлайн-Дневников_files/rMdMpGS2GLyh1cQuWKjaz7Szf5ZRaoKsgKlLvEFgV0Mc4Wkbney_pz4MdiIuWf0FwloL_2tA2z6ALPwwB_SGHk4z7DeRZimZYsfWrXsZei7zwayFN8rhLBOYC2gRo3Un7zAamg0dX0TuPSeivjl-tZH6SI7r0di98P-O0lRU5Q99cvxFYUcrOQGlxP66aCg-kAN95adYwqxi2loZ8bGW108T-Nvtzp9mTT_n4D5JjnVAOPmtK6EpTLIPfYK3VHT~20190220-150546: file name too long
As I understand it, the file (one of the resources of a saved webpage) is being deleted but it can’t be backed up to .stversions because the name becomes too long after adding a timestamp. The puller is then stuck at it and spams the log forever. Isn’t it possible to truncate the name so that it all fits? Maybe add an option for that if it’s not a preferred behavior? I personally wouldn’t care less if this seemingly random name is backed up with a slightly incorrect name. But it’s a chore to look through the log, ask the file owner if the file really IS safe to delete and only then remove it.
It’s got nothing to do with versioning, the simple delete command would fail too. And mangling filenames has been discussed and rejected many times before.
What do you mean? I can easily remove the file. The problem is that ST tries to add a timestamp to it and violates the length constraint. And it does it because it needs to put the file to the version storage. How should I deal with these situations if webpages are saved often?
Ah so you have filenames which are just below the limit and syncthing’s versioning pushes them just over? Sorry didn’t get that part (to my excuse, the names are really freaking long already before ). I thought we already had a solution for that scenario with mangling (because mangling versioned files and that we already mangle is obviously much less problematic).
I can’t quickly find any method which would shorten long filenames being used for versioning or conflict files, so my memory might be wrong. On second thoughts I also don’t see how Syncthing should even know when filenames are too long.
It’s only mangled in creating temp files (we use md5 of the file name if its too long when adding temp prefix/suffix), it’s not mangled in versioning and it makes no sense to mangle the name on versioning as you won’t know what file it is so sadly, no, we won’t fix this as there isn’t a universally accepted solution.
The answer is to not use versioning, (or use your own custom versioner that deals with this) or have shorter file names.
That’s sad to hear. The abstraction leaks and it’s no longer a “just works” solution that requires no maintenance. I hope you’ll reconsider. Since ST already has the index database, it might as well maintain a “versioning” database with mangled-to-full names mapping. On restore via the web UI these full names would be applied. Still, even a simple flag like “I don’t care about truncating file names, just don’t get in the way” for the versioner would help a lot.
). I thought we already had a solution for that scenario with mangling (because mangling versioned files and that we already mangle is obviously much less problematic).