What went wrong?
(Note: I do not have the technical programming background myself, so I used an AI assistant to help investigate why empty folders were being left behind and to locate the relevant source code in the repository.)
When sidecar files (.metadata.json, .cover.jpg) are enabled, deleting a book via the UI successfully deletes the book and sidecar files, but leaves empty directories behind on the filesystem.
This appears to be identical to #821 / #820 (which was fixed for file moves in #822), but overlooked in the deleteBooks workflow:
In backend/src/main/java/org/booklore/service/book/BookService.java (lines 428-434):
deleteEmptyParentDirsUpToLibraryFolders is executed BEFORE sidecarMetadataWriter.deleteSidecarFiles. Because the sidecars still exist when the empty-directory check runs, the folder is not considered empty and directory cleanup is skipped. The sidecars are then deleted immediately afterwards, stranding empty folders on disk.
Suggested fix: Invert the order in BookService.java so deleteSidecarFiles runs before deleteEmptyParentDirsUpToLibraryFolders.
How can we reproduce it?
- Enable sidecar files in Settings -> Metadata Persistence -> Sidecar Settings.
- Have a book stored in a subfolder (e.g. Library/Author/Series/Book.epub) with sidecar files (.metadata.json, .cover.jpg) generated.
- Delete the book via the Grimmory UI (confirming permanent filesystem removal).
- Inspect the underlying filesystem: the book and sidecars are deleted, but the empty folder shell (Library/Author/Series) remains on disk.
What Build of Grimmory are you on?
Stable
Your setup
- Grimmory Version: v3.3.3
- How are you running it: Docker (docker compose) with MariaDB backend
- Browser: Brave / Chrome / Firefox
- OS: Linux Mint (Linux kernel 6.x)
Screenshots or error messages (optional)
No error message is thrown in the container logs because the operation exits with code 0 (the directory check simply sees files and quietly skips directory removal).
Before submitting
What went wrong?
(Note: I do not have the technical programming background myself, so I used an AI assistant to help investigate why empty folders were being left behind and to locate the relevant source code in the repository.)
When sidecar files (.metadata.json, .cover.jpg) are enabled, deleting a book via the UI successfully deletes the book and sidecar files, but leaves empty directories behind on the filesystem.
This appears to be identical to #821 / #820 (which was fixed for file moves in #822), but overlooked in the deleteBooks workflow:
In backend/src/main/java/org/booklore/service/book/BookService.java (lines 428-434):
deleteEmptyParentDirsUpToLibraryFolders is executed BEFORE sidecarMetadataWriter.deleteSidecarFiles. Because the sidecars still exist when the empty-directory check runs, the folder is not considered empty and directory cleanup is skipped. The sidecars are then deleted immediately afterwards, stranding empty folders on disk.
Suggested fix: Invert the order in BookService.java so deleteSidecarFiles runs before deleteEmptyParentDirsUpToLibraryFolders.
How can we reproduce it?
What Build of Grimmory are you on?
Stable
Your setup
Screenshots or error messages (optional)
No error message is thrown in the container logs because the operation exits with code 0 (the directory check simply sees files and quietly skips directory removal).
Before submitting