I have several folders where I have closed PhotoLab, renamed both the image and .dop files then, later, reopened these folders, only to find that, although the file names are fine in the folders on disk, the file names on the vignettes are still showing the pre-rename name, but not necessarily on all versions of the same file!!!
Even if I delete both the database and cache, this is still the case.
The only way I have found to rectify this problem is to go into every .dop file and change the name in there.
@StevenL, this looks like one of those weird bugs that has slipped under the radar. Anything you can suggest, apart from âweâll put it on the todo listâ?
The other thought that just struck me was, if PL can show this name from the .dop file, even though the file name is totally different, have we found a way of renaming virtual copies?
@Joanna, in Windows I use IrfanView for renaming, if necessary (you remember, I had the problem, that I could not rename files inside of PL3). With IrfanView I can edit the filename of the image and the *.dop file at the same time - including the filename inside the *.dop file.
Any solution for virtual copies would be very nice. So we could give a hint in the filename about the changes for example.
Actually, Ralf, thereâs no need at all to rename the filename within the sidecar/.dop file ⊠This internal name doesnât seem to be used at all (at least, not for anything important/critical), and PL will update it the next time it encounters this {image+sidecar} duo.
[Iâm assuming you meant âVirtualsâ, not Vignettes, Joanna]
Thatâs a curious observation/experience - I do a LOT of renaming of {images+sidecar} files from outside PL, and with PL closed at the time of renaming, Iâve never seen that problem ⊠(tho, Iâm on Windows).
I have seen this problem if PL is running at the same time as the external rename occurs, in the following circumstances: If, say, you rename the image-file before the sidecar file (with a delay before the sidecar is renamed) - then itâs possible for PL to say âOh, look - thereâs a new image - Iâll create a new sidecar file to match it !â ⊠and then you have version confusion.
What I have found is that, despite deleting both the database and cache, I still canât get rid of the âghostâ file name unless I manually edit the .dop file. PL doesnât seem to know how to fix it, at least on the Mac version
This is not a problem on the Win version. When a pair of {image+sidecar} files are renamed from outside PL, there is no need to update the filename within the sidecar file ⊠PL does an auto-repair the next time it encounters this combo.
@StevenL: Just in case youâre monitoring this discussion; Please do NOT âfixâ this situation on the Win version (to have it behave the same as Mac) - as itâs extremely valuable being able to rename {image+sidecar} files from outside PL - with full confidence that PL handles this elegantly.
@John-M, I donât know exactely how IrfanView works. I just open the image file, press F2 and change the name. IrfanView changes the name of the image file and the *.dop file at the same time. And I even can do that while PL is open. I have done this many times because I was tired of this problem in PL3.
DPL4 on Mac does NOT fix the name or anything else in this case.
Iâve changed the names in Finder while DPL was running and I noticed that DPL flashes the new name for a split second and then returns to the original name or the one stored in the .dop file. Just for fun, I changed the name in the .dop file too and reimported the sidecar. Nevertheless, the name displayed is still the name when the file was opened for the first time. Changing the name (and .dop content) while DPL is off does not do any good either.
The database seems to be âstrongerâ than the sidecar or in fact a user action (import sidecar) in this case. In my opinion, a user action should override the database, which is what happens in DPL when I change exposure, WB etc. Renaming a file seems to be excluded though.
One small (missing) piece of the DAM puzzle
Indeed. Which is why, in the course of my investigation, I delete both the database and the cache after editing the .dop files - something that is not an option for those who make use of either projects or keywords.
While the image file and dop file in the finder are well renamed, the name of the file inside the dop is obviously unchanged, and by copying them into a new folder, DPL put the previous name in the thumbnail image, but the pop-up with information on the image is showing the new name.
Yes, this works fine with the Windows version of PhotoLab (and PL happily updates the filename stored within the sidecar/.dop file) - but, as reported by Joanna, and others, it does not seem to work with the Mac version.
On the Win environment, this ability to rename {image+sidecar} pairs, from outside PL, is an extremely valuable feature - which I use just about every time I use PhotoLab.
This might be the case with the Windows version but with the Mac version, the name in the .dop file is used for display on both the title bar of the window and for the thumbnails
âŠnot sure about that. I edited the name in the .dop file and nothing changed on title bar and thumbnailâŠ
Moreover, while I was fooling around with my tests, DPL started to create virtual copies. I therefore decided to delete database, cache and .plist files to make a clean slate.
I deleted the .plist files in my preferences folder. The ones for DPL and those for DPLâs workspace settings. Deleting all these files means that I had to redo settings and workplace to my taste.
As @John-M noted, I encountered the same problĂšme. He has put a link on the corresponding thread in itâs post.
Since using PhotoLab (version 1), I have always used Lightroom to manage images and therefore rename them. I have never had this problem before. But I canât say for sure if these images were renamed with Lightroom as I also tested PhotoLab 4âs batch rename feature.
As mentionned by @Joanna, during my tests, I started to see some weird things with virtual copies created on their own ⊠So I deleted the databases and config files to restart from scratch. Everything is back to normal regarding the virtual copies (except that the master images and the virtual copies seem to be inverted) but the problem of images names is still present.
)
)
