I have a problem with deletions, which are often not propagated successfully. This seems to be particularly true of photos, which never propagate a deletion.
When a file is deleted on one device, the file is initially deleted from other synced devices, but then reappears moments later as a zero length file. This file is then propagated back to the original device. Once this happens, these 0 length files are impossible to delete without removing the sync folder concerned from all devices, and recreating it from scratch.
This occurs, in my experience, on Windows and Android devices.
Is this a bug, or is there something about the setup that is causing this ongoing problem? It has happened in every version of ST since I first installed it about a year ago.
Judging by Google Play Store reviews, this is not an uncommon problem.
This sounds Android specific. Which is annoying and a bit exasperating as Android keeps doing funny tricks with it’s filesystem. It also means someone with an Android device needs to narrow it down to what’s actually going on at a low level. Reproducing this with STTRACE=model,scanner would be a start.
Sorry I may have misread your post. I have now entered ‘scanner,model’ instead of ‘scanner,mode1’ which has been accepted. I’ll come back when I have something.
I deliberately deleted a .jpg file, and it reappeared as described above as a zero length file, first on the receiving device, then propagated back to the sending device (where the file was originally deleted).
Attached should be log outputs from Syncthing, from both devices. Also the resulting zero length file.
I uploaded 4 log files and a .jpg, though I think this last may not have uploaded as the upload came back as unable to determine its size.
The debug option was set on both sides.
Sorry, first time I’ve tried to send files in this forum, must have got it wrong.
I used the “Upload” button, and it seemed to do something as it asked me to select files, and then gave me the undetermined length error message for the jpeg file.
I’ll try again.RECEIVER Android Log.txt (38.1 KB)
RECEIVER Syncthing Log.txt (13.7 KB)
SENDER Android Log.txt (49.5 KB)
SENDER Syncthing Log.txt (14.9 KB)
That looks better. The jpg was the first file, and the upload must have failed at that point.
I hope there are now 4 .txt log files, the filenames should be self explanatory.
Here is another example (output from Syncthing with Debug Mode set to “scanner,model”).
Before this test, I completely reset up Syncthing from scratch, using v0.8.4 (as 0.8.6 crashes regularly), the deletion behaviour is the same.
File ending ‘09.png’ was deleted from directory emulated/0/Screenshots on device H1.
The deletion is initially propagated to device H2 by Syncthing.
The file then reappears on device H2 with a file length 0.
The 0 length file reappears on device H1.
This behaviour can be replicated on demand on any version of Syncthing I have ever installed.
Below are the logs. If a search is done to highlight ‘09.png’, errors can be seen, though they mean little to me.
I hope this issue can be addressed, from Google reviews it is obviously a common problem.
From the log on H2 it looks like a rescan event for the …-09.png file comes in pretty much immediately after the delete, presumably from the inotify handler. My interpretation is that we delete the file, something else recreates it as a zero byte file (maybe the camera app does this due to thumbnail generation or whatever) and we get told to rescan it, and it gets resurrected.
I’d be interested in hearing if this happens with something that is not 1) Android and 2) involving photos.
I have definately had 0 length files on my Windows laptop, but could not say whether they originated there, or were created due to being propagated from an Android device.
2)I’m not sure about non-photo files.
I’ll try and test out both those, but it won’t be until tomorrow now.