Errors during applying IPTC information

[kclaar]

Kirk,

The behavior is this: When updating a single image, no IPTC data is erased. When updating a group of images via the IPTC panel, when PM+ encounters the first read-only file, that file's IPTC information is removed. If you look at the first image from my post above, the selected image (#118) has the IPTC data removed (it had the same data as #117). That behavior seems odd for a read-only file.

Hope that explanation helps.

-- Ken

[Kirk Baker]

Ken,

The behavior is this: When updating a single image, no IPTC data is erased. When updating a group of images via the IPTC panel, when PM+ encounters the first read-only file, that file's IPTC information is removed. If you look at the first image from my post above, the selected image (#118) has the IPTC data removed (it had the same data as #117). That behavior seems odd for a read-only file.

If you quit PM and reopen it, is the information still missing?

-Kirk

[kclaar]

Kirk,

The answer to your question is yes, the IPTC data is not there upon reboot of computer and restart of PM+.

With the information we've been exchanging, I conducted a controlled test. I took 8 images, and set read only on 3 of the images. I selected all 8 images, used Ctrl-I to bring up the IPTC panel, cleared it, and checked the Caption checkbox. Applied to all 8 images, and now color me confused... all 8 image captions updated, no errors.

Reopened the panel (Ctrl-I) and added text to the Caption field, updated the group of 8 images, and all updated again, even though 3 files were tagged read-only.

-- Ken

[Kirk Baker]

Ken,

The answer to your question is yes, the IPTC data is not there upon reboot of computer and restart of PM+.

With the information we've been exchanging, I conducted a controlled test. I took 8 images, and set read only on 3 of the images. I selected all 8 images, used Ctrl-I to bring up the IPTC panel, cleared it, and checked the Caption checkbox. Applied to all 8 images, and now color me confused... all 8 image captions updated, no errors.

Reopened the panel (Ctrl-I) and added text to the Caption field, updated the group of 8 images, and all updated again, even though 3 files were tagged read-only.

Could you post a screenshot of your IPTC/XMP settings?  Use the 'Attachments and other options' link when you're composing your reply to this message and there you'll be able to upload your JPEG format screenshot.

Thanks,

-Kirk

[kclaar]

IPTC/XMP Preferences...

[Kirk Baker]

Ken,

I'm surprised that you're able to update a NEF that is read-only since you have RAW files set to embed metadata (not using XMP sidecar files).

-Kirk

[Hayo Baan]

Hi Kirk,

I have made some simple tests and found this is indeed a bug in PM: even if the image is read-only, PM still updates it. To reproduce:

Case 1 – image without .xmp:
1. Mark image as read-only
2. Apply a change to the metadata
3. Update is saved to file even though it was marked read-only

Case 2 – image with .xmp:
1. Mark both image and XMP file read-only
2. Apply a change to the metadata
3. You now get an error that there was an error updating (caused by the XMP file), the image file, however, is still updated (the xmp is not).

In both cases the image should not have been updated as it was marked read-only.

[Odd Skjaeveland]

...In both cases the image should not have been updated as it was marked read-only.

If the file is read only in file/operating system terms, I would tend to think that the system would deny any write attempt from an application like PM?

[Hayo Baan]

...In both cases the image should not have been updated as it was marked read-only.

If the file is read only in file/operating system terms, I would tend to think that the system would deny any write attempt from an application like PM?

Yes, that would be expected if they write to the same file. But what I think is done is that they write a temp file and rename/move that over the old one. In that case the r/o flag could get circumvented perhaps…

[kclaar]

Kirk,

I have additional detail. This may be a timing issue with how PM is handling updates to image files. Again, I;m updating the image files, not using sidecar xmp files.

1. I am working with a set of images generated by a Browse of a keyword (I'm updating keywords in the images.
2. All files, including folders,  were set to have the read-only flag turned off.
3. I'm using the IPTC panel that is generated from the image, not a global Ctrl-I.
4. Every so often, about every 10 images or so, I run into a read only image (Read only appears in the PM window title)
5. Checking Windows 10 Explorer for the file attributes of the file, it shows NOT read only.
6. If I cancel the IPTC panel, and re-open it from the image (i), it is NOT read only, and all works fine.

Attachments 1a and 1b are taken when the error occurs; 1c is after exit and re-open of IPTC panel. Also, I turned Debug ON and attached the log file.

I know on the surface, this does not make much sense. I'm a retired IT developer (mainframe, mini and PC). All I can say is that my debugging has been step by step. Something is going on in the PM file system.

Thanks!
-- Ken Claar

[kclaar]

Additional info to above post:

Using the navigation arrows (<) and (>) to move either forward one image or back one image, then returning to the image that was read only also works so I can continue (the read only message is removed)

[Kirk Baker]

Ken,

Additional info to above post:

Using the navigation arrows (<) and (>) to move either forward one image or back one image, then returning to the image that was read only also works so I can continue (the read only message is removed)

So if you make no changes with PM and only look at the Metadata (IPTC) Info, sometimes the images are "Read-Only" and if you navigate back to them again, they won't be "Read-Only" and this is without making any changes in PM?

-Kirk

[kclaar]

Unfortunately, yes.

[Kirk Baker]

Ken,

OK, and if you look at the actual files in Windows Explorer, are they marked as read-only at the time that PM is saying that they're read-only?

-Kirk

[kclaar]

They are not - see file explorer snipet above. Only the Archive bit is set.