• Global community
    • Language:
      • Deutsch
      • English
      • Español
      • Français
      • Português
  • 日本語コミュニティ
    Dedicated community for Japanese speakers
  • 한국 커뮤니티
    Dedicated community for Korean speakers
Exit
1

"Error writing metadata to" message and extended attributes

Community Beginner ,
Jan 21, 2012 Jan 21, 2012

Copy link to clipboard

Copied

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

Views

19.9K

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Jan 21, 2012 Jan 21, 2012

Copy link to clipboard

Copied

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.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
People's Champ ,
Jan 22, 2012 Jan 22, 2012

Copy link to clipboard

Copied

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

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Jan 22, 2012 Jan 22, 2012

Copy link to clipboard

Copied

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.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
People's Champ ,
Jan 23, 2012 Jan 23, 2012

Copy link to clipboard

Copied

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

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Jan 23, 2012 Jan 23, 2012

Copy link to clipboard

Copied

Omke,

I repoect that DNG works so well for you, and I hope you can respect that I have no interest in it. And when I say that DNG is beside the point, what I am referring to is that I am after a discussion/solution of the issue I'm describing, not a discussion about the merits of DNG. If I have a problem with the roof of my house I'm not reallyintered in hearing about how great it is to live in an apartment. As for support of future file formats, I have much more confidence in the continued support of the file format from the manufacturere than I do of a file format from a company that doesn't even make cameras. But as you say, so many users so many workflows.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
People's Champ ,
Jan 23, 2012 Jan 23, 2012

Copy link to clipboard

Copied

As for support of future file formats, I have much more confidence in the continued support of the file format from the manufacturere than I do of a file format from a company that doesn't even make cameras. But as you say, so many users so many workflows

While I had no intention in saying what you must do only what you could do (nor do I disrespect your workflow), it's fine by me you do feel that way, no problem.

And also no problem in your believing of the current 200 different Raw file formats that will be still supported in about 20 years by the same camera manufacturers (Minolta is not producing camera's nowadays, yet they where the first with AF systems. Olympus might also not be there in a few years)

With every new camera there is a new Raw format, do you really think in twenty years time the maybe 1000 different Raw files will stay supported by the new software and OS of that future time??

While I have great respect for vendors like Canon and Nikon regarding their production of camera's, I really have never enjoyed the software they produced, it is very limited in editing, very slow and therefore unproductive. And I never understood why they have to produce a new Raw type for each new camera.

And by the way, if you use Bridge it might be safe to assume you also use ACR. Until now Adobe, the company that knows next to nothing of the production of camera's but almost everything about the software to use for working with the digital data from that cameras, has been so kind to offer support for almost all that different code of Raw freely.

Personally I have more fait in the open standard DNG provides, but as said, no problem you do believe the camera vendors will do support all their own created types of Raw, even if don't sell them anymore for 10 years:-)

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Jan 23, 2012 Jan 23, 2012

Copy link to clipboard

Copied

Omke, you seem to be wanting a discussion/arguement about the merits of DNG vs other raw formats. Unfortunately, I'm not interested in having one. Perhaps you should post your thoughts somewhere more appropriate, since this thread is certainly not the correct place for it.

In any case, please consider this reply my last to you on the topic of DNG files. If you have anything to contribute regarding my original question, I'd be happy to hear it.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
People's Champ ,
Jan 23, 2012 Jan 23, 2012

Copy link to clipboard

Copied

If you have anything to contribute regarding my original question, I'd be happy to hear it.

Mike, your reference to the roof and the apartment did get me started on the wrong foot, occasionally one needs to get rid of some steam...

That said, I stopped using the sidecars XMP years ago and did not realize the keywords are also in the XMP sidecar.

I also was under the impression you were trying to write keywords to an XMP file itself. As also said, less knowledge about terminal, also having a cold and a failing graphic card and running behind on schedule while using the old insufficient one and waiting for the replacement to come.

About the extended attributes, you are in good hands now with Paul

It might be useful to tell whether the files are from one shoot and one camera in a series and have already metadata written to before?

How do you import them and if not shot with same camera same shoot did you use other converting software?

Biggest problem for Bridge when writing keywords that it does not go on in the background and you need to wait for all to be applied, if not you end up with insufficient result, however I never experienced an 'error to write metadata to' message, only found out that some files did miss the applied keywords.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Valorous Hero ,
Jan 23, 2012 Jan 23, 2012

Copy link to clipboard

Copied

To me it sounds as the problem is outside Bridge. In an XMP file the first bytes should be a UTF-8 marker. Try copying a couple of cr2 files to another folder and delete the xmp sidecar files, now add metadata using Bridge and have a look at the new sidecar files.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Jan 23, 2012 Jan 23, 2012

Copy link to clipboard

Copied

Hi Paul,

When I describe the contents of the file in my original post, I am describing the extended attribute for for the XMP file, not the XMP file itself.

When I do as you suggest the keywords are applied without issue to a new XMP file, which is the normal expected behavior.

I think the most maddening thing about this is the idiosyncracy of it.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Valorous Hero ,
Jan 23, 2012 Jan 23, 2012

Copy link to clipboard

Copied

Hi Mike, I was not familiar with that extended attribute, It gets even stranger as I tried removing the attribute with:-

xattr -d com.apple.FinderInfo filename.xmp

This did remove that attribute and I was still able to add metadata, after the metadata was added the attribute was back again.

So the problem may be with the xmp file format? These that do not work, do the xmp files contain any data if so what?

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Jan 23, 2012 Jan 23, 2012

Copy link to clipboard

Copied

Paul, that's the exact behaviour I am seeing. The only difference is that if I try to leave the addition of the attribute to Bridge, it is not added each time...sometimes it takes a couple refreshes, or leaving the folder in question and returning back to it again.

And to top it all off, the more I try to employ my findings, the less convinced I am that I was right: I have batch-added the attribute to every JPG, CR2 and XMP file in my test folder, and still I am getting the error box. It is absolutely maddening.

When the XMP file exists already, it contains whatever information LIghtroom saves to it when the "Automatically export changes to XMP files" option is clicked; I'm afraid I'm not familiar enough with the contents to determine if the error lies with a malformed XMP write...although I doubt this is the case, as the trouble seems to be with files that don't have XMP files too, just as unprocessed RAW files adn JPG files.

What would be really great would be to get a trace of what bridge is doing so I could debug this myself, but when this error occurs no log file is updated that I can see...at least nothing tracked by Console on OS X.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
People's Champ ,
Jan 24, 2012 Jan 24, 2012

Copy link to clipboard

Copied

When the XMP file exists already, it contains whatever information LIghtroom saves to it when the "Automatically export changes to XMP files" option is clicked;

Mike

If we would try to reproduce the error message could you provide the version numbers you use for Lightroom, Bridge and OSX?

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Jan 24, 2012 Jan 24, 2012

Copy link to clipboard

Copied

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!)

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Jan 24, 2012 Jan 24, 2012

Copy link to clipboard

Copied

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

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Jan 24, 2012 Jan 24, 2012

Copy link to clipboard

Copied

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.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
People's Champ ,
Jan 25, 2012 Jan 25, 2012

Copy link to clipboard

Copied

(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!)

Sadly enough I can't disagree with you on the tech support, however, officially Adobe Bridge is not supported nor designed for working on a server. Just a stand alone configuration.

Did you also try a purge cache, there can be a lot of issues with corrupted cache and the cache for Bridge is not always that stable.

Still no clue on what versions are being used?

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Guest
Jan 25, 2012 Jan 25, 2012

Copy link to clipboard

Copied

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

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

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Jan 26, 2012 Jan 26, 2012

Copy link to clipboard

Copied

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.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
People's Champ ,
Jan 26, 2012 Jan 26, 2012

Copy link to clipboard

Copied

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.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Jan 26, 2012 Jan 26, 2012

Copy link to clipboard

Copied

The first problem you will encounter Omke is that the issue is very idiosyncratic. But let me give you the steps I would follow were I to try and reproduce the issue from scratch.

1. Take a collection of about 1000 CR2 files that have had no adjustments done to them of any kind: no keywords, no ACR, no LR, no nothing.

2. Import these files into LR

3. make some changes to the photos using the sliders in the Library or Develop modules. No keywords at this point.

4. exit LR

You should now have a set of CR2 files with corresponding XMP files. If you do not, re-open lightroom and make sure to automatically export changes to XMP files is selected.

It would be interesting to drop to a terminal and do ls -la@ at this point to see what if any extended attributes have been created.

5. Open up Bridge, but do not browse to the folder containing the RAW files yet. Instead, make sure you have a few keywords in your keywords panel, and that panel is visible.

6. Now, browse to the folder containing the RAW files

At this point, and before caching is complete, try to apply a keyword to some of the file by selecting about 20 and clicking the keyword to apply. This fails more often than not, but is not the real issue

7. Once the BR cache is complete, select all and apply one of the keywords. This is where it fails for me.

Some things that may be affecting this issue:

1. The aforementioned lack of the extended attribute on the XMP file

2. Older XMP files created with older version of LR and ACR may be a incompatible in some subtle way

3. It seems that the "Export cache to local folders" setting may be involved in this bug somehow

...Mike

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
People's Champ ,
Jan 26, 2012 Jan 26, 2012

Copy link to clipboard

Copied

3. It seems that the "Export cache to local folders" setting may be involved in this bug somehow

Mike

I do have to get back on the try with 1000 files, the files are there, the time not really...

Regarding to applying anything while cache is not completed will be dealt with an 'as designed' answer but you are aware of that yourself.

The point 3 about cache to local folders might be of more interest. I have a longstanding failure of that function because every time I set this function the first time everything works as expected and after a while, mostly second time, I get an error about not able to write the cache due to a CacheT. error.

This has been a mystery to me and also still to Adobe. For a long while I thought I was the only person on the world suffering from that failure but a short time ago Kevin, a regular on this forum, did report the same error.

I also have to say I'm not bothered with that failure because I don't have the need for it. Cache is still a problematic subject for Bridge.

While I use Bridge to great satisfaction for sorting, rating, metadata and shortcut to ACR and PS I think it is next to useless to use Bridge as a DAM for archiving purposes. I used to burn cache file to disk long ago but reading this file was almost as long as building new cache, just a few versions ago they changed the cache format every cycle etc etc.

Using 55 K of 'keepers' in an archive with Canto Cumulus Single user this cache file is about 2GB in size. I regular delete the Bridge cache file because 10 % of this amount in Bridge generates about 10 GB of cache and it keeps growing fast.

So it might be a good try for you to first have a fresh start with cache, plist and prefs. When refreshing prefs it should also deselect the export cache to folder by default but be sure to check it is off.

Will try later on to reproduce, thanks.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Feb 02, 2012 Feb 02, 2012

Copy link to clipboard

Copied

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.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
People's Champ ,
Feb 03, 2012 Feb 03, 2012

Copy link to clipboard

Copied

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.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines