@platypus Just about to go out to get the new header tank etc. before I resume my “day job” as a “plumber”!! Thank you for your response it appears that PL5 on the PC is somewhat better behaved than on the MAC on this occasion (although that could be a function of the DB software used?).
Because of the limitations of the file management in PL5 (possibly because they want to avoid all the work involved in not only doing the actual file management but also trying to keep the database inline with those changes) users will always have to resort to external file management and PL5 will then have to play “catch up”, but that “catch up” should be “elegant” and not leave elements hanging.
I think I would raise the issues as a ‘bug’. Sadly my investigations do not help @zkarj at all in this case because of the differences between the MAC and Win10 PL5.
If you want to use private messaging with me then by all means do e.g. to draw my attention to an item that I appear to have ignored and you want tested on Win10,
@platypus will check that out later after I have collected my bits, bought some more copper, built a new platform for the new header tank, plumbed it in, removed the blockage (the real hard part), refilled the system and restarted the central heating - it could be a while!
Exactly, and that does not work if the file is no longer there.
Which either of these would fix.
I do think there is some caution to be applied to the last one, though. When I have elected to move images outside of PL, I have been able (with some difficulty) to tell it where they had gone and get them linked back up. If the database were to automatically “get rid of” any entries without matching files, this process would no longer be possible.
The simplest thing for DxO would be to get a copy of Lightroom (I’m sure that they have one) and see how Lr manages to prevent inconsistencies - and then add what is missing.
2 Likes
Stenis
(Sten-Åke Sändh (Sony, Win 11, PL 6, CO 16, PM Plus 6, XnView))
26
This is one of the things with PhotoLibrary that has to be sorred out when people now really has started to use PhotoLibrary that really is version 1.0.
People that use PhotoMechanic or other similar software to manage metadata and cull images I’m pretty sure is doing that in the system that owns the metadata instead of doing it in Photolab. So that’s just another reason to get a more advanced solution if you are unsatified right now with these features. Still there are workarounds like reindexing it all or just the folders that are out of sync to solve the problems so it’s not something you can’t fix.
I write a little script, e.g. in Python, which creates in the folder, where the “phantom files” are displayed in PL, empty files with the names of the missing files – of course including the filename suffix.
DXO will display them with an exclamation mark because the files are found but cannot be read (of course…).
Now, it’s possible to delete those files from within PL, and they’re gone from the library.
Attachments are restricted to certain file types and new users have more restrictions in what they can attach. But you could share the script with a file share or sharing service like wetransfer.com.
What is the thing that tells your script to create a file? Some “reality check” info in the database? …?
If there were only a few missing files, you can create them manually e.g. with a plain text editor (as bbedit or brackets) and give them the names of the missing files, including their suffix.
In my case, there was a whole series of missing files, because deleted the dngs created by Lightroom Classic in favor of the Raw files in order to use the lens sharpening tool.
So there was a series of files with consecutive numbers as distinctive part of the file names. I could generate them using a simple loop in Python.
The only important thing for PL in order to be able to delete the orphaned file names from the database is, that there is a file holding the respective name, which PL can move to the operating system’s trash.
Here is my script:
for i in range(5100, 5272):
f = open(f"IMG_{i}.dng", 'w')
f.close()
This created empty files with names from IMG_5100.dng to IMG_5271.dng.
