Accidentally renamed sync target folder -- data loss on source?

#1

Hi Forum,

rather carelessly, I changed the name of my synchronization target folder “D:\MyFolderName” on my PC ‘B’ today.

The source folder is a network drive which is displayed on my laptop ‘A’ with a network drive letter like this: “Z:\MyFolderName”. Synchronization is set up both ways (“Send and Receive”).

After a few minutes I stopped the synchronization. However, Synctrayzor already had thrown lots of tray icon messages on PC ‘B’ like “couldn’t delete folder XYZ” (or something similar).

Now I’m worried that on the sync source network drive under “Z:\MyFolderName”, hundreds or thousands of files/folders may have been already deleted.

Which of the Synctrayzor or Syncthing log files would I have to look into to find and trace down any possible deletions on that network drive “Z”?

Emergency assistance would be much appreciated :o

#2

So on B the Syncthing folder root is at “D:\MyFolderName” and you renamed that to something like “D:\MyRenamedFolderName” - correct? If it is there was no syncing, but the folder was stopped on B with an error complaining about a missing folder marker. You should see that in the web UI of B.

And I don’t understand how the source being a network drive plays into the description of your setup. As far as I understand PCs A and B share a (Syncthing) folder which is located at at “Z:\MyFolderName” on A and “D:\MyFolderName” on B. Due these paths/locations have any connection outside of the shared Syncthing folder?

1 Like
#3

Exactly.

I panicked and removed all sync tasks on both laptop A and PC B – so can’t really see that in the web UI anymore. However I think I copied all log files from A – so in which log file could I be able to find that ‘missing folder marker’ error (or entries about possible file/folder deletions)?

“Z:\MyFolderName” on laptop A is a mapped c*mpany network drive, to which however PC B has no access.

Laptop A seems to have full read/write access to that mapped network drive, that’s why I’m worried about possible file/folder mass deletions.

#4

Instead of search logs (see below) you can also disconnect the devices by pausing (just for your peace of mind, not strictly necessary) and unpause the folder on device B. Then that error should come up again.

That error would be on Device B, as it’s there the folder root vanished. From the point of view of Syncthing it doesn’t matter that you renamed it, there’s just nothing anymore at the root path so it throws an error (there is a hidden folder at the root that also got moved, and when that is missing, Syncthing throws this error).

The latter part was important. So for the purpose of debugging this this network mapping is not relevant - which wasn’t clear to me before.

1 Like
#5

So am I getting this right, you are saying that Syncthing normally would have stopped syncing as soon as I renamed that “MyFolderName” folder on B?

That would be such a relief!

And provided this should be about correct – which log files on A and/or B could I check for any possible further things that may have happened?

#6

Yes.

There’s just one log. With synctrayzor I think it’s even displayed in the wrapper itself, otherwise you probably find the location in it’s settings. On linux (generally without a wrapper) it just logs to stdout, which usually goes to the system log if run as a service.

1 Like
#7

This is probably one of the sweetest “Yes’s” ever received. I can’t thank you enough :pray::pray::pray:

OK will check that!

I have the further phenomenon that the discussed mapped network folder “Z:\MyFolderName” is displayed on Laptop ‘A’ with about 60 GB, 40,000 files and 9,384 folders – when I scan it with WinDirStat.

The locally synchronized folder “D:\MyFolderName” on PC ‘B’ (which I had synchronized for months) has exactly the same number of folders, but (again according to a scan with WinDirStat) only about 3,500 files and 1.7 GB.

What could be the reason for that…? Are there so many junk files on the network drive that SyncThing does not synchronize 90% of the files already with factory settings?

I have only specified ~*.* as file ignore pattern, in order not to synchronize temporary MS Word files.

#8

Sorry this seems to be an error at my end.

Will check and report back

#9

Yeah, there went something wrong at my end when moving the sync target folder.

I used FreeFileSync for this (because, other than Windows Explorer, it retains folder creation dates). However I fear that FreeFileSync has other problems that can lead to data loss on syncing (moving) files.

1 Like
#10

Hi @David.P

if you had Syncthing’s Versioning feature turned on, you might find your “deleted” files in the hidden .stversions subfolder of your Syncthing shared folder. I guess that from your different folder stats.

1 Like
#11

FreeFileSync may not be syncing empty and/or hidden folders.

1 Like
#12

I can’t seem to locate that hidden folder in my sync target folder. What would that folder be called, and what should it contain?

(I am about to move my sync target folder to another hard drive like discussed here, specifically in the way given here.)

Do I need to have that hidden folder in order to successfully move my sync target folder, and start syncing it again?

#13

.stfolder - see https://docs.syncthing.net/users/faq.html#how-do-i-rename-move-a-synced-folder.

1 Like
#14

Thanks for that link!

I actually went about it exactly like specified over there:

The easy way to rename or move a synced folder on the local system is to remove the folder in the Syncthing UI, move it on disk, then re-add it using the new path.

However, I swear that there was no hidden .stfolder – at least not after

remov[ing] the folder in the Syncthing UI

Though now, after

re-add[ing my sync target folder] using the new path

…there is a hidden .stfolder in the sync target folder.

It also seems the folder is syncing (have set it up as “receive only” for the time being).

#15

That’s actually correct. When the folder is removed in Syncthing, it also removes that hidden folder.

2 Likes
#16

Thanks for the much appreciated information