Switching from Syncthing (deprecated Android or Fork) v1 version to v2.x

Catfriend1 · September 9, 2025, 12:36pm

Hi,

Is there an easy way to detect when the migration to v2 has completed, so it would be okay for the wrapper to delete the v1 db dir afterwards?

A user has asked me to delete the index-v14 folder, but I don’t want to blindly rmdir because the wrapper might maybe kill the v1 dir while migration is still going on.

Is there, for example, a file in the v2 dir I could check if it exists to see that migration was fully completed? Or does the config.xml contain some hint after a successful migration I could check for without much code ? Does v2 first migrate the v1 config or v1 db?

olifre · September 9, 2025, 12:58pm

Hi,

thanks for taking this to the forums!

There is one additional ingredient here: syncthing renames the old database directory to index-v0.14.0.db-migrated after the migration is complete. I think this is the cleanest way to detect that the migration is finished. The other indicator I know of is the entry migrated-from-leveldb-at in the new main database (see syncthing/lib/syncthing/utils.go at 8233279a6576af8aa4839318fa454720c21385b1 · syncthing/syncthing · GitHub and syncthing/lib/syncthing/utils.go at 8233279a6576af8aa4839318fa454720c21385b1 · syncthing/syncthing · GitHub , the latter is essentially the list of indicators). If there are other indicators, I am sure someone will comment here.

The message Old-style database present but already migrated will only be shown if a database directory with the naming scheme v0.14.0.dbis brought back afterwards (which, in my case, happened due to config export: If target zip file exists already, content is added (i.e. old content not purged) · Issue #1615 · Catfriend1/syncthing-android · GitHub ). There is no warning (yet?) if a v0.14.0.db-migrateddirectory remains.

olifre · September 9, 2025, 1:12pm

It’s -migrated, see:

github.com/syncthing/syncthing

lib/syncthing/utils.go

8233279a6


      
          
          	slog.Info("Migrating virtual mtimes...")
          	if err := ll.IterateMtimes(sdb.PutMtime); err != nil {
          		slog.Warn("Failed to migrate mtimes", slogutil.Error(err))
          	}
          
          	_ = miscDB.PutTime("migrated-from-leveldb-at", time.Now())
          	_ = miscDB.PutString("migrated-from-leveldb-by", build.LongVersion)
          
          	_ = be.Close()
          	_ = os.Rename(oldDBDir, oldDBDir+"-migrated")
          
          	slog.Info("Migration complete", "files", totFiles, "blocks", totBlocks/1000, "duration", time.Since(t0).Truncate(time.Second))
          	return nil
          }

olifre · September 9, 2025, 3:09pm

Thanks! Note that index-v0.14.0 (if that was brought back e.g. via a config import) may of course remain present this way and might irritate users by the warning in the webinterface, but I’m not sure there is a good way to get rid of this (apart from checking whether the migrated marker is in the database).

Syncthing itself also seems to do cleanup of old migration artifacts, but not for the v1=>v2 migration yet:

github.com/syncthing/syncthing

cmd/syncthing/main.go

8233279a6


      
          func cleanConfigDirectory() {
          	patterns := map[string]time.Duration{
          		"panic-*.log":        7 * 24 * time.Hour,  // keep panic logs for a week
          		"audit-*.log":        7 * 24 * time.Hour,  // keep audit logs for a week
          		"index":              14 * 24 * time.Hour, // keep old index format for two weeks
          		"index-v0.11.0.db":   14 * 24 * time.Hour, // keep old index format for two weeks
          		"index-v0.13.0.db":   14 * 24 * time.Hour, // keep old index format for two weeks
          		"index*.converted":   14 * 24 * time.Hour, // keep old converted indexes for two weeks
          		"config.xml.v*":      30 * 24 * time.Hour, // old config versions for a month
          		"*.idx.gz":           30 * 24 * time.Hour, // these should for sure no longer exist
          		"backup-of-v0.8":     30 * 24 * time.Hour, // these neither
          		"tmp-index-sorter.*": time.Minute,         // these should never exist on startup
          		"support-bundle-*":   30 * 24 * time.Hour, // keep old support bundle zip or folder for a month
          		"csrftokens.txt":     0,                   // deprecated, remove immediately
          	}

calmh · September 9, 2025, 3:14pm

We will add code to remove the migrated v0.14 database. I didn’t do that initially in order to tread carefully.

olifre · September 9, 2025, 3:15pm

Understood.

For such users, the following recipe might be helpful (just in case you ever need it or someone arrives here by searching, writing it down):

After DB migration is finished, do an export to a new config file location (config.zip must not exist yet, otherwise old DB will remain in there and new DB will be added to it).
Purge data of Syncthing app (or uninstall / reinstall).
Import from the export above.

This way, the old database is cleanly gone (both the -migrated artifact and also old databases which might have come back via the import).

olifre · September 9, 2025, 3:19pm

Thanks, that’s very understandable and appreciated.

One question: Will the future code remove only index-v0.14.0.db-migrated or also index-v0.14.0.db in case that came back e.g. from a backup, restore or something similar (like the config import on Android)?

If index-v0.14.0.db-migrated will be purged, I think this will obsolete: Clean up legacy migrated index directory before Syncthing start by Copilot · Pull Request #1622 · Catfriend1/syncthing-android · GitHub . If index-v0.14.0.db will be purged, too, it will also solve any issues with reimported old backups etc. But of course treading carefully is even more critical there.

calmh · September 9, 2025, 3:27pm

The -migrated one will be deleted. If you put back an old index-v0.14.0.db you’ll trigger a new migration on next startup, effectively undoing whatever has been stored in the new database since. Don’t do that.

(The presence of both old and new database is effectively a signal that the migration failed partway through and must be redone.)

olifre · September 9, 2025, 3:34pm

Thanks for confirming!

@Catfriend1 Since that essentially happens if users follow the recipe:

Export from v1 app.
Uninstall v1 app, and install v2 app.
Import config.
Re-export into the same config.zip location (to have a backup in case of catastrophe). => config.zipwill at that point contain the original v1 database (without the -migrated suffix) and the new v2 database.
At a future point in time, reinstall and import from said backup.

I believe that is dangerous, as it may trigger another migration at that point, as the original database index is put back in parallel to the v2 database.

One idea to solve this (without touching the config export code) would be to add the following step to the migration guide (at the very end):

Before performing another config backup, make sure to purge the existing config.zip.

Would it be reasonable to add this as protection against such broken backups?

olifre · September 9, 2025, 3:39pm

Nevermind, I see you just did this:

That will solve the issue described above .

Catfriend1 · September 9, 2025, 3:43pm

Yup .

olifre · September 9, 2025, 4:15pm

Thanks, I think this protection here in SyncthingNative saved the day:

github.com/syncthing/syncthing

lib/syncthing/utils.go

8233279a6


      
          	if when, ok, err := miscDB.Time("migrated-from-leveldb-at"); err == nil && ok {
          		slog.Error("Old-style database present but already migrated; please manually move or remove.", slog.Any("migratedAt", when), slogutil.FilePath(oldDBDir))
          		return nil
          	}

i.e. the marker in the new DB caused the old DB to be ignored and the warning to be shown.

So in fact, the re-migration was avoided, which is good to see, and since now the old DB is never present of new exports anymore as the ZIP is purged beforehand, we’ll be safe .

Thanks for doing the tests and confirmation, also of the new cleanup code!

calmh · September 9, 2025, 7:10pm

Ah, yes, I had already forgotten I put that in. Nice.

AllonZ · September 16, 2025, 7:35pm

Thanks for posting how to get rid of the Old-style database present but already migrated message @olifre!

Worked like a charm!

system · October 22, 2025, 6:37pm

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.