Known Participant

Question

"Error writing metadata to" message and extended attributes

Forum|Forum|14 years ago
January 22, 2012
5 replies
21376 views

After being frustrated by this error message in Bridge while trying to apply keywords to various image files I finally took the time to investigate, and I think I found the cause of the issue. In a nutshell, if the extend attribute "com.apple.FinderInfo" has not yet been created for a given file, then this message appears.

The start of the puzzle was that some files would take the keyword and others would not. After observing identical permissions on files that worked and files that did not, I noticed that in a terminal listing of the files in question, some files had extended attributes and some did not (extended attributes are identified by an @ symbol when running ls -la in a terminal window. For example:

-rw-rw-rw-@ 1 mike staff 26131946 21 Jan 23:56 120114-133059-4612.cr2

-rw-rw-rw- 1 mike staff 5710 21 Jan 22:42 120114-133059-4612.xmp

-rw-rw-rw-@ 1 mike staff 27200794 17 Jan 17:52 120114-133145-4613.cr2

-rw-rw-rw- 1 mike staff 5702 21 Jan 22:42 120114-133145-4613.xmp

-rw-rw-rw-@ 1 mike staff 26973498 21 Jan 23:07 120114-133149-4614.cr2

-rw-rw-rw-@ 1 mike staff 6648 21 Jan 23:19 120114-133149-4614.xmp

As you can see, the file called 120114-133145-4613.xmp has not extended attribute, but the file 120114-133149-4614.xmp does. The former throws an error when applying a keyword, the latter does not.

So I dug a bit further and it appears that when the file attribute called com.apple.FileInfo is missing from an xmp file, metadata cannot be witten. The contents of this extended attribute for a working XMP file look like this

$ xattr -l 120114-133058-4611.xmp

com.apple.FinderInfo:

00000000 54 45 58 54 43 52 61 77 00 00 00 00 00 00 00 00 |TEXTCRaw........|

00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

00000020

According to specs I found googling, the first 4 bits identify the file type (TEXT), and the next four identify the file creator (CRaw). IOW no file-specific info seems to be present.

So as a test, I simply copied the contents of com.apple.FinderInfo from a file that had it to a file that didn't. Once the file that didn't received the new attribute, metadata writes worked. The command I used for the copy was

xattr -wx com.apple.FinderInfo "`xattr -px com.apple.FinderInfo 120114-133534-4633.xmp`" 120114-133041-4602.xmp

It also appears that this metadata is written by Bridge based on some unknown trigger, because occasionally during my investigation a file that previously would not take metadata suddenly did, and once I knew to look for extended attributes, in every case the file in question suddenly had com.apple.FinderInfo extended attribute.

So...I'm not sure if this is a bug in finder or in bridge, but it is definitely a bug and needs to be addressed.

...Mike

This topic has been closed for replies.

T

theMikeDAuthor

Known Participant

At this point I can confidently say that if Bridge was a person, I would be in jail for homicide. There is just no way I can get this to consistantly work. I am beyond frustrated at this program that can't seem to get its raison d'etre solved after four versions any better than ACDSee on a PC did ten years ago. Coupled with the obtuse error message this generates, I doubt there is a solution we can come up with that is going to fix this bug or even provide a work-around.

So...I give up.

Omke Oudeman

Participating Frequently

So...I give up.

Mike, I'm sorry to hear that, and I just finished testing but cannot replicate your issue.

Copied 1089 CR2 files form 4 different dSLR (1D2, 1D4, 1Ds2 and 1Ds3) and followed your instructions to the letter.

No change in result for terminal either, not after LR and not after Bridge. I have a few issues with the @ sign but not for xmp files nor for CR2.

Bridge did cache the correct settings I added in LR (a did overdo color and contrast so no doubt in visibility).

While caching I could add keywords that where present as well as creating a new keyword and sub keyword. One remark, only a few did get all the keywords, others only half the amount. However this was done without error message and due to the fact I did to many to much in one time and did wait for proper saving for each keyword. When I only choose two or three keywords and just select them in one go after each other they save all with no problem, when I again click one or two while the other bunch is still saving it does not work properly, but again, without a warning message.

Saving in background for ongoing tasks would be better but this is not the case for Bridge, also usually I don't use such large amount for so many keywords. As said above, I have tried again after all the caching and saving was done and it was no problem to add a few keywords in one go to all the files, took about one minute to save the metadata to all the files.

Maybe you will give it one more try after having dumped the central cache file from the user library for Bridge and camera raw. Delete the plist and restart with option key to reset prefs. Be sure to have deselected the option to export cache to folder.

I've used LR 3.4.1 and Bridge 4.0.5.11 on MacOs 10.6.8. All files where on the start up disk (2TB with 750 GB free space) and 16 GB RAm on a Mac Pro.

Omke Oudeman

Participating Frequently

I just noticed that there may be some interaction between Photomechanic and Bridge. Try this:

Put about 20 RAW files in a folder.
Make sure all of them have at least one keyword applied that is nested in another (so, Places -> Canada, and Canada is selected)
Close bridge
Open that folder in PhotoMechanic
Pick the first ten images and rename them using the rename function (left click the selection)
Close PM and open bridge
Try to apply a new keyword to the renamed files

My result is that the renamed files throw the error, and the other files do not.

Try this #2.

Put about 20 RAW files in a folder.
Make sure all of them have at least one keyword applied that is nested in another (so, Places -> Canada, and Canada is selected)
Close bridge
Open that folder in photomechanic
Pick the first ten images and adjust the time of the RAW file (Tools, Adjust capture dates and times...). Doesn't matter by home much.
Rename them using the rename function and this rename code: {year2}{month0}{day0}-{hour24}{min}{sec}
Close PM and open bridge
Try to apply a new keyword to the adjusted and renamed files

My result is that the adjusted and renamed files throw the error, and the other files do not.

Using BR 4.0.5.11 and PM 4.6.8

I just noticed that there may be some interaction between Photomechanic and Bridge. Try this:

Mike, will try it when having some spare time. Don't have Photomechanic and will try to get a demo version to test.

Meanwhile be aware that this forum is soon to die and set to read only, you have to move the discussion to the new Bridge General Forum, links for this are on top of this Mac Forum page.

or send me a private message

A

Anonymous

You might look at this thread from the Windows Forum with a similar topic.

http://forums.adobe.com/thread/888123?tstart=0

T

theMikeDAuthor

Known Participant

Omke, the versions of the software don't seem to be relevant, but since you ask: the current version of Bridge I am using is 4.0.5.11. Some of the existing XMP files were written by older versions of Lightroom, but I have no way of knowing which.

I have tried purging the cache, and also deleting it entirely and starting over, to no effect.

Omke Oudeman

Participating Frequently

I have tried purging the cache, and also deleting it entirely and starting over, to no effect.

Mike

just did a quick try and don't know if it is the right way.

Using Lightroom 3.6 (not very familiar with Lightroom) and Bridge 4.0.5.11 on MacOSX 10.6.8

I randomly choose some CR2 files that where somewhere on my system and copied them to a new folder. Imported them in Lightroom and added some rating and a few keywords. (with setting metadata to XMP file active)

Then went to Bridge and opened the same folder. After caching Bridge showed the info as filed in Lightroom. Added some keywords to all files without problem. Went back to Lightroom (restarted it and had to choose read metadata menu. After this no problem to read new keywords form Bridge. But they only show in Italic because the have not been made persistent in the Bridge keyword list, however this is as expected behavior.

Tried a develop setting and that was also showing in Bridge correctly. Went a few times back and fort (files in Lightroom showing a memo with Exclamation sign top right of the in Bridge changed thumbnail asking for reading metadata).

Is this about the way you mean to describe?

And when having set Automatically export changes to XMP have you set this option in both Lightroom and Bridge (this s to be found in the Camera Raw preferences 'save image settings in: sidecar XMP')

And there are a few things to refresh also in Bridge besides the deleting of the cache file, you can also delete the Bridge plist file from the user library preferences and restart Bridge holding down option key and chose reset preferences. And did you run the check and repair permissions for your system also?

I tried to look in terminal but could not find a way to use the ls -la command on the folder with changed files so no comparing on that side I'm afraid.

W

winstonoboogeee

Participant

The Bridge error of not writing metadata has been a problem since version 4. Adobe refuses to acknowledge the problem and, after many, many discussions with their tech support, I gave up trying. The problem occurs with RAW, DNG, and JPEG's, at least for me. It seems to have something to do with images that go from a server and back to a Mac or only reside on a server.

From trying to diagnose the issue, I believe it's a thumbnail corruption problem. I have found, quite often, this will fix the problem:

1. Get info on an image (command + i)

2. Delete the thumbnail by clicking on the thumbnail and hitting the delete button

3. Bring the images back into Bridge, then control + click or right click and select "Purge Cache of Selection"

4. Restart Bridge (this isn't always necessary)

That will usually fix the problem. Today's it's not working for me. The other option is to stop using Bridge and switch to a more stable, and supported app like Photo Mechanic.

(My frustrations with Adobe technical support and this problem are IMMENSE. Their support has to be one of the most incompetent I've ever dealt with in recent years. They'd ask me the same question three times and I'd respond each time only to have the ask the exact same question again!)

T

theMikeDAuthor

Known Participant

Winston,

Interestingly, none of my images have a thumnail in the Get Info window. I think it has to do with some subtle interaction between bridge and OS X attributes...but I can't seem to put my finger on it yet. Do people using Windows have this issue? If so that would seem to rule out my idea.

Do you have the "Automatically export cache to folders when possible" option in Bridge turned on?

...Mike

W

winstonoboogeee

Participant

Hi, I does not matter if you have an actual icon of the image in the preview. I've delete them both with & without a preview image and it seems to help. Try deleting the blank preview icon, it might help.

Omke Oudeman

Participating Frequently

So...I'm not sure if this is a bug in finder or in bridge, but it is definitely a bug and needs to be addressed.

While terminal is somewhat above my knowledge I'm not sure I understand your problem. I'm under the impression that you want to write keywords to an XMP file?

The XMP file contains the settings for ACR and rating and labeling from Bridge while keywords are part of the IPTC written to the file info of the file itself.

Or am I misunderstanding you?

Personal I stopped using CR2 years ago and switched to converting to DNG on import. DNG writes all data to the file, including XMP

T

theMikeDAuthor

Known Participant

The problem is simply this: it appears that keywords cannot be written to XMP files by Bridge until the extended attribute com.apple.FinderInfo is aplied to the XMP file. XMP files potentially contain a great amount of information, keywords being one of them. Also note that the descision to write keywords to the XMP file is made by Bridge, not me.

DNG is not an option, and in any case is beside the point.

Omke Oudeman

Participating Frequently

DNG is not an option, and in any case is beside the point.

So many users so many workflows. DNG is a valuable option, Downloader also offers the option to back up the original CR2 when converting.

And to my opinion DNG is not beside the point, DNG is becoming more and more the standard and most likely the format that will let you open the archive Raw file in years to come without the need of using an old computer because the current software from the future does not support the file format any longer...

Although my knowledge is still limited in the department you are talking about it is my believe that the XMP data for keywords is in the file info and not in the side car XMP file.

Anyhow, using vital information for a file and save this info in a separate file is for me a no go

T

theMikeDAuthor

Known Participant

This may also be a lightroom bug or a lightroom/OS X interaction issue if com.apple.FinderInfo is not created for the XMP file when LightRoom creates it via the "Automatically write changes to XMP" option in the LR Catalog preferences.

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded