pull: no such file

Support
#1

I had an unfortunate idea to try Syncthing on FreeNAS. As the synchronization went on so did “something else” in the background, to the point of where i got the error “pull: no such file”. This error did no exist before, so i assume ZFS or something is to blame. The version of Syncthing on FreeNAS was 1.4

The problem persists when trying to sync the same files on Debian. Windows do not complain. I did not try it on macOS.

If i open a file (like image or pdf) and save it, without any changes done to it, just overwriting the existing file, the problem goes away.

Does someone have a better understanding of this? Is there a way to mass-change files (attributes) in the command line? Probably is, but what to change?

#2

That error means that the remote device it is requesting data from, doesn’t have that data.

What exactly did you do: Did you share an existing folder with the FreeNAS device? Did you copy the data to FreeNAS in advance or was the folder root empty when you started this? How old is the folder in question (i.e. does the error come up on really old data that hasn’t been touched in years)?

#3

There was no data on the FreeNAS, it was empty. And yes, interestingly the problem does seem to be with the older files.

#4

Are we talking early 2017 and older? Then you might be affected by the same problem I was last week and fixed in master (thus proving wrong my assumption that no-one but me will profit from the fix :slight_smile: ). I can’t link to it right now, as github is having troubles (will do later).

If that’s really your problem: To mitigate right now disconnect the new device (freenas) - it would just forever keep the other remotes busy (invalidating and rehashing files, using cpu). How to proceed from there depends on what risk level you accept: You could run master or backport the fix, however that’s always risky and definitely in this case (it’s a small, but rather fundamental change) - I have it running on my systems but that’s about the testing it got for now. You could wait for v1.8.0. Or you could rebuild your database on old devices (those also running since <2017).

#5

Hmm yes it seems the problem files all have “last change” date 2016 and older, although one txt file with change date in 2016 is not causing any problems while PDF and image files are. Thank you for the help. I chose the safe way and will wait for 1.8

1 Like
#6

I think I am experiencing the same problem – repeated “pull: no such file” messages on old files (cerca 2011). I removed the folder containing the old files from Syncthing on the machine where it was added, and the problem cleared up. I will wait for 1.8 before adding that folder again.

#7

This issue is seriously affecting my clusters. We’re talking 25 folders distributed over 10 instances. I run backup nodes that connect to all instances and pull all folders; when trying to add a new backup node yesterday, all folders spam the console with “no such file” messages.

I tried removing a single (small, test) folder on all instances and adding it again, which unfortunately changed nothing except that now I can’t use that folder anymore, which previously worked fine.

Am I understanding this thread correctly? I won’t be able to add ANY new instance that use ANY existing folder from another instance until either 1.8 comes out (potentially months from now), or I tear down every last instance and set the whole cluster up again to “rebuild the database”?

#8

Is there a way we make a v1.7.1 release with one week time to test out there (like rc) where the fix is back-ported?

#9

Recreating my database solved the issue for me but that’s hardly a solution.

Renaming or duplicating the files in a separate folder didn’t help.

#10

Touching the files should be sufficient.

#11

Too many of my files are affected by this bug to solve this manually. Are there other options?

EDIT: I shut down all my syncthing instances, went to %localappdata%/syncthing or .config/syncthing and deleted the index-v0.14.0.db directory, then brought up all instances again but with connections being paused, waited for all scans to finish and then re-enabled connections.

#12

I’ve prepped a hotfix for this with what I think is the fix for the issue, but not able to validate it. If someone wants to try a 1.7.1 candidate, it’s here:

https://build.syncthing.net/buildConfiguration/Syncthing_Release_ReleaseSyncthing/74991?buildTab=artifacts&guest=1

2 Likes
#13

The 1.7.1rc fixed my issue. :+1:

1 Like
#14

Looks like it fixed it for me too, thanks a lot!

1 Like
#15

If it didn’t, for anyone, the 1.8.0-rc.1 candidate out now contains the more complete change for these things.

#16

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.