-
Matěj Laitl authored
This fixes data-loss that I can trigger every time by toggling "Local Files & USB Mass Storage Backend" in Config -> Plugins, restarting Amarok and triggering collection update / rescan. In theory, more things such as cloning changing disk could trigger this problem, from SqlScanResultProcessor::deleteDeletedDirectories() comment: We need to match directories by their (absolute) path, otherwise following scenario triggers statistics loss (bug 298275): 1. user relocates collection to different filesystem, but clones path structure or toggles MassStorageDeviceHandler enabled in Config -> plugins. 2. collectionscanner knows nothings about directory ids, so it doesn't detect any track changes and emits a bunch of skipped (unchanged) dirs with no tracks. 3. SqlRegistry::getDirectory() called there from returns different directory id then in past. 4. deleteDeletedDirectories() is called, and if it operates on directory ids, it happily removes _all_ directories, taking tracks with it. 5. Tracks disappear from the UI until full rescan, stats, lyrics, labels are lost forever. Also add a handful of asserts, ScanResultProcessor is very complicated and small error or corner-case in logic may result in horrible data losses. Reporters of linked bugs, please try to reproduce your data-loss with this patch applied and report back in both cases. In negative case, please reopen and attach full updated amarok --debug log. After this patch, only (statistics, lyrics and labels)-loss operations should be: a) moving track out of mounted collection folders [by design] b) changing both metadata and url from outside of a track not tagged by amarok_afttagger [we can do nothing about this] BUG: 298275 FIXED-IN: 2.6
5a0d3d39