Both sides of the connection are Send & Receive. I’m not sure why the NAS thinks that file is 0 bytes? The modifying device also should be the laptop, not the NAS.
I tried enabling the various debugging facilities but couldn’t track down much regarding this file or why it’s failing to transfer. I could probably fix the issue by resetting the database on TrueNAS, but I would much rather determine why this is happening, as it’s not the first time I’ve run into issues like this.
If it’s a configuration issue at the heart of it, I’d like to fix it permanently.
same thing happened to me with an working audacity file ( file.aup3-wal) although the audacity project was saved a year ago, syncthing considered the file was locked.
I had to reopen the project under audacity, get the message ‘this project was not saved properly’, save it and quit.
this removed the ‘wal’ file thus my problem.
for your case
check if a process is attached to your file ( with ‘fuser’)
I wrote working audacity file ( file.aup3-wal) although the audacity project was saved a year ago, syncthing considered the file was locked
Of course the file was not locked by a process anymore. I don’t know how syncthing was stuck on that particular file, but on other side this file was a subset of the projet “file.aup3”, and when I reopend that project, I got a warning message from audacity about not properly saved project.I find it ok if syncthing don’t try to sync such working files.
now what are unf files ?
WAL files are usually database files that are not “written to” in a normal way, they are memory mapped, and memory is modified, which changes the file content without changing the modification date, so syncthing has no way of knowing that the file has actually changed.
In general, you will struggle to sync files like that, as databases/wal files are not intended to be sync’ed and are used as crash safeguards, so syncing them is generally a bad idea.
Also, what does
syncthing considered the file was locked
mean? I don’t think syncthing cares about locking as long as it can read the file.
Confused as to the first part of this, was that directed at skysyncth94?
The file I’m syncing isn’t any sort of WAL, it’s just a config dump from a Unifi controller. essentially just an archive with a bunch of text configuration files in it.
Also, there is a known bug that we’ve been trying to track down for a while with no success where status reporting is simply incorrect between devices.
You could try removing and readding the folders on both sides.
You can tell this from the fact that the total file count is different I suppose? Wish I could be of more help with reproducing the bug, but I went weeks without noticing that this file wasn’t syncing.
Honestly it’s not important anymore, I have more recent backups. Just going to delete the file.
I don’t think so either, but I can’t think of any other explanation, other than an unfortunate coincidence that would have caused me to see the same symptoms as Bladewdr on a ‘work file’ type file.
As for the date of the file, that is a good explanation, but not in my case, since I saw this bug appear on a first synchronization performed after Syncthing had been set up, much later than the persistent creation of this wal file.
Honestly it’s not important anymore, I have more recent backups. Just going to delete the file.
this means that It’s not a work file, it’s a normal file generated by Unify, just like an .aup3 is the saved result of an Audacity session, which blows my hypothesis out of the water and confuses this topic (sorry).
So this bug would be random, without being able to determine the reason for its appearance at the moment.
