Document or fix potentially dangerous side effect of `-reset database`?

Development
1

I’m in the process of documenting the behaviour of -reset-database.

I’m concerned that documenting the behaviour of a potentially dangerous side effect may not be the right long-term course of action. I’m still happy to do it in the short term, if it’s deemed appropriate though.

I have a few concerns with -reset-database or its REST equivalent:

  • It doesn’t follow the principle of least astonishment
    • It sounds like it only changes the database, but it changes sync folders also
  • It creates a .stfolder if one doesn’t exist in a sync folder
    • This could be very bad where a sync folder is an unmounted external drive, filling up a laptop’s small internal disk
    • If the external disk is mounted later, it will then mask the data written to the internal disk

Wouldn’t it be better to:

  • Not create .stfolders
  • Only scan / update the database for the folders which syncthing has marked as it’s own (ie, .stfolder exists)
  • Update the documntation of -reset-database to say:

    Reset the database, forcing a full rescan and resync of all currently available sync folders.

2 Likes
Recreate synced folders after data loss
2

-reset-database is indeed incredibly dangerous.

Without the database, the situation is as if you had just installed Syncthing and hand written a config file. It would be surprising if it refused to sync the folders you point to and require creation of magic hidden files.