Using Mac OS X:
I import some JPG files, then deleted them from my Tropy catalog (.tropy file), “standard” format. I right-clicked the “Deleted Items” and chose “Permanent Delete”. The JPG files disappeared from the catalog.
However, when I open the .tropy file (using right-click, “Show Package Contents”), the JPG files are still in the “assets” folder, taking up room on the drive.
Shouldn’t they be gone, freeing room?
Have you closed the project yet? The files should get removed the next time the project is closed.
However if something goes wrong during the deletion it’s possible that files will stay in the store. It’s possible that this happened in your case. We actually need to add maintenance function which compares all files in the store with the project database to detect if there are any leftovers.
This happened to me as well.
Environment: Mac OSX, Intel, Version 1.16.2 (x64)
I am using standard mode, where photos are copied into .tropy package.
After using tropy to delete the photos following the two steps (soft delete then permanently delete), the items are gone in tropy but the images within .tropy/assets are still there.
After opening and closing Tropy, the files remained.
Can you check if the file is not referenced by any item anymore? You can see all the known checksums in the Terminal if you use the path to your project file like this:
sqlite3 Documents/name.tropy/project.tpy "select checksum from photos order by checksum"
This will print all the checksums in alphabetical order.
Was the deleted photo a single page or part of a multi-page file (like a PDF)?
The deleted photos include both single pictures and also PDFs.
I includes the counts from the sqlite query and the counts from the assets folder.
Is it safe for me to write a script to remove all the files whose checksum IS NOT in the sqlite database?
ls -al assets/ | wc -l
578
sqlite3 ./project.tpy "select checksum from photos order by checksum" | wc -l
37
sqlite3 ./project.tpy "select checksum from photos order by checksum" (base)
005258fb8fd71295a028bcd0278ceb4b
0221639b395e63bbc8a49ee76aa04b6a
218d374f78d8dac10aae7698b0efa72a
23cb732f93c554c21a6982a0a070eafc
2a8bb2669bedd965595dca7395c02954
2f0e5e5196d71e3ab592d147faf800f8
2f0e5e5196d71e3ab592d147faf800f8
3845ab77f2e2a7f1d9a0ee738bb2dee0
43fd1ca0b9a5c6cc58a8336c761ab5cf
4468cf93aebfdf18be7602d666ad4dd5
4a2bdc188b547ca086b620cbed4c64d8
4ab46bbdd4d40b3a1ac0e9dfaae4a866
4ab46bbdd4d40b3a1ac0e9dfaae4a866
56fc672dfbec3f08423b0542eab925d1
57177abc5e8218076e1ef36fcd0b8378
65bbf1fc7319974b2732e86df256b93a
68440261707eed136bb61746a3326eae
6ddfbe6923862dd3e16e2d14ee9c7355
704cb3a96d158f22f761555a9219a15d
7810e5a2e44d9f975a56c45d48b85a80
806c053c99be1e5e8b2853801709ea09
806c053c99be1e5e8b2853801709ea09
85042091aa678671c09b62563438d635
85fbe41dd6eb493543822cfeb87974f2
8b6b91188ea4e67f93d711c2237cd5e2
a0a03772ecf7f59aee7bcefe68bfda95
b28e2d41dc04c112d246f1c69a654fef
c0debc8763287efb4c394b087d8b49aa
ca945e2a123891a05f324c4f422fd751
ca945e2a123891a05f324c4f422fd751
cc2113be6252ad4a8e9a4c48662313f2
d668c92c39705ecbb5d379d116eb93a3
f165e1b012b89ca922594878810f98fc
f319fd1c26e36dc0797df9ba58b2d253
f38b1ba0b7c6e29ab61035d9468236b1
f58430bdf9a5b8b5634e3a8d1dc9e263
fa52b4a496ceef4d1166ff5877e1d147
Are those files in a synced folder? I wonder if that has something to do with it. After permanently deleting the files in Tropy, Tropy should move them to the Trash when you close the project. There’s a chance that this fails if there is a crash when you close the project, but it’s really unlikely that this happened so consistently, so there must be a reason why Tropy was unable to remove the files.
In any case, yes, if the checksum is not in the project database it should be safe to remove the file. I would err on the side of caution though and move the files out first and later delete them when you’re sure they’re not needed any more.
We’ll add a script like this to the upcoming release as well.
Indeed it is within a Dropbox sync folder, likely the Dropbox’s extension interrupts the deletion. I don’t think this is a high priority issue, but if there are logs I could capture for sequence of events, I would be happy to reproduce them and capture in a GH issue for later.