new to digikam. I see it uses a database, so I assumed that if it were to ‘take ownership’ of any of my files - eg such that a delete would remove the (originals) from disk, it would be loud, clear, and well-documented.
So I create a quick ‘dummy’ album, and create / delete. Digikam sees to copy (??) every photo/video locally into $HOME/root_album/some_album/dummy-folder-name-i-added
Interest piqued, I look around at my filesystem:
48gb== my original/preexisting folder of pictures (a syncthing share local folder FWIW)
37gb == the same folder in the matching $HOME/root_album/some_album/...
(both sizes obtained with du -sch)
what on earth is going on??
why are they different sizes on disk?
more importantly, why for a database-based photo manager is digikam copying all my files? (Those can’t be thumbnails or previews at that size)
And if it wants to, why was this not made clear when I add folders the existing large folder?
in the docs, how am I supposed to tell what the heck happens, big picture, to my critical data, when i try to delete these albums?
my original source folder, and the one digikam created in ~/Pictures/ are on this same FS
as best I know, zero sym or hardlinks in the source directory; it’s basically just a flat Syncthing sync of the android DCIM folder on my phone …
I’ve never had occasion to notice/care, but as I think you imply yes du -sch is counting fragmentation / total inodes/pages it appears. So it makes sense the fresh, ~linearly copied set is less on-disk space page-wise
but wouldn’t it be nearly identical in actual “apparent” file size after the copy?
re-running the size as du -scb (or specifically find . -type f -print0 | du -scb --files0-from=- | tail -n 1 to only count files not any directories) I see a difference of the original sources is 1.84Gb larger. 5%? 5% difference isn’t a lot in one sense, but in the case that I wasn’t told digikam would consume this space, and it offers no explanation why it would be so different (like stripping all metadata, re-rendering(unlikely) etc?
Obviously I’m trying to first ensure that I can use the UI without inadvertently deleting my whole folder of pictures … but also understand how a new user is supposed to interact with this software, in the hopes that raising this leads to (at least) a doc update, if not a wizard and menu change in the program:
I take it from your comment that import is explicitly copy-all-the-files (such as if you’re reading them from an SD card where that makes sense). But re-reading the quickstart, and browsing all the menu entries - it’s not at all clear to me what else I was supposed to do.
Or once I somehow got my album to somehow just pull from my existing folder, how to safely “un link” it if I needed to re-do something, without digikam trying to trash all the files.
As I understand it, you are complaing that the files imported into $HOME/root_album/some_album/ by DigiKam appear to take up less space than the files that were synced into a syncthing share local folder.
several things. the theme is (1) I don’t want to inadvertently delete my work (and despite RTFM’ing I cannot get a clear answer from the docs), and (2) as a developer (in an unrelated space) and FOSS advocate I hope pointing out these (significant! IMHO) new-user doc/UX flaws might help get an issue submitted to make (at least a doc) improvement.
some more specific examples:
I did import to “add” my folders, because that was (still is) the only applicable option I see in the docs or browsing the UI. I should have been informed this would copy
especially since the program can see I’m copying to the same FS which at least as I’m inferring from responses here is probably the “wrong action by user”
This should be discoverable/learnable with at least a simple skim of the docs and(or) ui menus.
explanation of digikam’s use of root album / collection is woefully inadequate. It’s variously called a collection in the docs, and it appears to be treated specially by some places where one should be able to add a new root ablum. Such as these two bugs I just submitted:
no easy way for the user to understand / find built-in trash (such as saying where it (the trash) is during the deleting prompt which (thankfully) is very explicit about what images/folders you’re deleteing.
Creating the database and linking t an existing Folder of Images is part of the initial set up process.
It’s like step do this step do that, in a Wizard style set up process. Digikam will then auto update the database with the file data.
Of course if you want to make sure there is a backup of the Files and you are prone to deleting files then you have done the right thing by Importing, and thus creating two copies of the Images.
When a File is moved to Trash from within DigiKam the File remains in place in the Filesystem. It is Flagged in the DigiKam database as ‘Moved to Trash’.
It is only when you empty the Trash that the file is actually deleted from the filesystem.
No I didn’t actually know that until I looked, but it seemed the logical thing for the Devs to do (and it’s what I would have done), as the point is to be able to restore the file, if you change your mind… and NOT simply delete files willee nilly.
I’ve used DigiKam since at least Version 1.0. I’ve never read the documentation. How it works seemed quite logical to me, as discover-ability seems quite easy.
I’m observing a discrepancy no matter how I account for space, and thus logically wondering if I know what the hell is going on, or not (because if not → that’s how accidents happen).
<I’m replying to posts as they were posted; more consolodated might be easier?>
When a File is moved to Trash from within DigiKam the File remains in place in the Filesystem. It is Flagged in the DigiKam database as ‘Moved to Trash’.
It is only when you empty the Trash that the file is actually deleted from the filesystem.
No I didn’t actually know that until I looked, but it seemed the logical thing for the Devs to do (and it’s what I would have done), as the point is to be able to restore the file, if you change your mind… and NOT simply delete files willee nilly.
I’ve used DigiKam since at least Version 1.0. I’ve never read the documentation. How it works seemed quite logical to me, as discover-ability seems quite easy.
The setup wizard was fine (although it’s UX should IMHO make some obvious key details more explicit).
But once complete, one immediately starts running into mixed/overloaded use of some very central terms (Album, Collection, Root-album) that are critical to predict other behavior; two examples:
what deleting means / where one can look for the mentioned trash,
how to “plan” for how to structure Collections, Root-albums, etc such that they co-exist with other solutions (eg monthly backups, cross-device photo syncing, etc - all of which ~everyone will manage differently and digikam doesn’t&shouldn’t manage itself)
Given that the folders created by DigiKam take up less space than those created by Syncthing, I would suggest you look in the syncthing folders for hidden dot files, or some other config files that DigiKam ignores.
The Trash Virtual Folder is usually at the bottom of the Albums Tree, in my experience. I’ve never seen it placed anywhere else.
The option in the context menu for the selected Image(s) is ‘Move to Trash’ selecting that option flags the Image(s) as ‘Moved to Trash’, and they appear in the Trash Virtual Folder, instead of their original Folder.
All ‘Folders’ in DigiKam are Virtual, so they don’r have to follow the underlying Filesystem. The structure you create in DigiKam is stored in the DigiKam Database.
You can create any virtual structure you choose.
I prefer to create a tree that goes
Albums
Pictures
Year
Month
date (yyyy-mm-dd)
for Processed Photos, those that I have processed from RAW to jpeg ot tiff
and
Albums
Photos
Year
Month
date (yyyy-mm-dd)
For the RAW images from the Camera.
The RAW images are actually stored on my File Server. While the processed images are stored locally.