Some files ended up as conflicts, some are just gone. Noticed it because it tried to delete some directories which it could not like for example:
[AGR6N] 2018/02/13 13:42:08.855203 rwfolder.go:1796: INFO: Puller (folder pi1-freigabe, file "..."): delete dir: directory is not empty
something else that appears in the log quite often is
[AGR6N] 2018/02/13 13:34:49.407153 rwfolder.go:1796: INFO: Puller (folder uberspace-agraf, file "..."): finisher: file modified but not rescanned; will try again later
will keep it in this state for now for debugging.
GUI also does not seem to load correctly on some devices, folders show unknown, remote devices show nothing. Any hints on how to debug it are appreciated.
Backup from this morning exists so at least no data lost, and this is a nice reminder for everybody that syncthing is no backup
This happened to me too! Suddenly noticed lots of deletes (thanks to SyncTrayzor’s notifications). Going to have to dig through the logs and find out what was deleted now, ugh.
Same thing here and thank goodness I have backups. An explosion of inexplicable conflicts (e.g.: truecrypt containers that haven’t been mounted in months, jar files that should never change, etc) and what looks to be lots of deleted files.
Probably 100GB or so of data I’ll have to sift through and verify now. I think I’ll be permanently opting out of rc builds.
No commonality that I can see between the files that were conflicted/removed between Linux, MacOS and Windows and I don’t use ignores.
As far as deleted files, it seems syncthing was really keen on removing directories that were in fact not empty and most of the files/dirs in question had mixed case but that shouldn’t have really been a problem because most of these were one-way replication setups so there were no actual changes to replicate from the source.
Closer examination of my conflicted truecrypt volumes seems to indicate that they are different valid versions of the volumes which suggests that at least one of the members in my replication pool had older versions that were never kept in sync (which is obviously a problem in itself). It’s possible that me resetting the database on one of my nodes triggered that?
Finally, as others have stated, the GUI seems to become unresponsive and some nodes aren’t establishing connections so that sounds like a deadlock of some sort.
@alyandon Is that the full panic trace, or is it truncated? It’s odd if it’s not truncated, there should be more things happening… Or rather, it’s deadlocking on a lock, but there is only one routine visible trying to get the lock and no-one else in that section, according to the trace.
(Don’t think is related to us eating your data by the way)
Ran into this behavior this AM when after starting up SyncTrazer that upgraded to 0.14.45-rc.2. Posted an initial bug report here (with screenshots of the SyncTrazer browser interface and output from console).
I can confirm that the content of several folders were deleted. Not individual files within certain folders; always the entire content of folders. I sync between Windows and Debian. The naming convention of folders varies. The start with lowercase letters, uppercase letters or numbers.
No;
I use a Master SyncThing server. Changes on remote devices get uploaded then distributed to other devices. Some of the folders that’s content was deleted have not been touched in months or longer. Other ones are more recent and are profile folders from portable versions of Firefox and Google.
EDIT:
I should qualify that the update happened on a Windows box this AM. The files were deleted on my portable copy of Synchting. I have yet to verify, if those files were actually deleted from my Master SyncThing server.
