spacedrive
spacedrive copied to clipboard
Desktop app fails to open after moving directory that is linked to a Location
Describe the bug
Hello,
I encountered an issue while testing PR #627. If you move or remove a directory that is linked to a Location while the app is closed, the app fails to open in subsequent executions. The terminal display messages indicating that the backend is initializing, but it will remain stuck. I found that the only way to restore the app to a functional state, aside from deleting the database, was to restore the linked directory to its original path.

I believe the problem happens during the instantiation of the Node type here, specifically in the loop that adds already existing locations to the location management in the Node's constructor logic:
https://github.com/spacedriveapp/spacedrive/blob/0fd53d1287455a036ddf7aab9499a96065c91176/core/src/lib.rs#L132-L164
I concluded this because the debug message "LibraryManager initialized", that is printed at the end of LibraryManager::new, shows up in the terminal, but the "Watching locations" message, which is supposed to come after the mentioned loop, does not get outputted.
Reproduction
- Run desktop app
- Create a Location
- Close desktop app
- Move or remove the directory linked with the added Location
- Attempt to open desktop app
- Desktop app fails to load and terminal stay stuck with
DEBUG sd_core::library::manager: LibraryManager initialized
Expected behavior
Desktop app opens, after external modifications to Locations linked directories
Platform and versions
$> pnpm --version && cargo --version && rustc --version
7.29.3
cargo 1.68.0
rustc 1.68.0 (2c8cc3432 2023-03-06) (Arch Linux rust 1:1.68.0-1)
$> uname -a
Linux arch.shadowverse 6.2.6-201.fsync.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Mar 15 04:41:53 UTC 2023 x86_64 GNU/Linux
Stack trace
None
Additional context
CPU usage while the app stuck is low, so it seems to be stuck waiting something, maybe an async task is not concluding for some reason:
