Bridge 4.1.0.54: Error writing Metadata to some [....].jpg

I keep having this issue and have had it for about two years now. I have tried all the steps suggested in all the responses (and then some) to no avail. Any help other suggestions?

and I still have trouble writing keywords to some TIFF files.

Can you specify the file name convention you are using, just a wild guess but sometimes extra dots or strange characters can cause problems. I cant recall having problems with writing keywords to Tiff but I mostly use PSD so not that well a good tester for your problem.

If ACDSee can write the keywords to a tiff file and Bridge not then there is a serious problem going on, and you should try tech support for Adobe (Not easy, I know) but that would be the correct path to follow.

It is not a bug.  It is how the OS system sets up permission levels in both Win and Mac. 

haggest wrote: I believe its a question of Win7 ownership and permissions. I believe that the for some reason the physical drive I moved from my old PC to my new PC retains "ownership and permissions", so Win7 notes all of the folders as read-only, and won't write the metadata to the jpegs in that folder.

You are correct.  Files made on another computer do not have the same permission levels as ones made on the same computer

Here is a solution from Pixel Basher

The key to solving this issue lies is understanding that in terms of Windows 7 Security, every internal or external hard drive, plus folders, sub-folders and files thereon has an OWNER. Also each OWNER has a certain level of PERMISSION to do things such as moving files to a different folder, deleting or re-naming them etc. If you try to do things that you don't currently have Permission to do, that is when you get an ‘Access Denied’ error message. Also your system has an Admistrator or Administrators and at the outset you need to ensure through the Control Panel that you are listed as one of them. .

If, like me, you didn't realise these things, (and why would you if Microsoft or your computer or hard drive suppliers couldn't be bothered to really make sure you knew about them), then trying to fathom the ‘Access Denied’ problem becomes a stressful and frustrating nightmare as I can testify having spent a week at it!

The steps that I took to resolve the issue and which I believe now constitute the 'Correct Answer' are as follows:

1. First make sure that you have Administrator rights on your system via the Control Panel
   
   
2. Next ‘right click’ on the Drive whose files you want to gain full access to, for example the drive that your pictures are stored on, and click on 'Properties'.
   
   
3. Under the Security tab you will see a list of Groups and Users on this drive and the Permissions that they have to do things.
   
   
4. Before doing anything to edit these Permissions, first click on the Advanced button. This opens another window with a tab showing the Owner of this drive.
    
   
5. Click on the Owner tab and if you are not already listed as the owner, make yourself the owner by selecting your name from the list. I believe it should appear there if you are an admistrator or user. (In my case at this stage the owner was initially shown as an obscure string of numbers and letters which I believe identified the drive when it was connected to the lap top I was using before I upgraded my machine)
   
   
6. Now be sure to check the box that says "Replace Owner on Subcontainers and Objects" and the click Apply. On completion of this step, the drive in question and all the folders, subfolders and files thereon should now be 'owned' by you. You could check this out by right clicking on a particular folder then clicking Properties > Security > Advanced > Owner. Your name should appear. So far so simples!
   
   
7. Now go back to the Security Tab for your drive (Step 2 / 3 above) and look at the Permissions you currently have. Your aim now is to allow yourself 'Full Control.' If you don’t currently have this level of permission click Edit, select your name on the list, check ‘Full Control’ and 'Apply' the change.
   
   
8. I think I'm right in saying that at this point whilst still working in the Drive directory you are now given the option of ticking boxes which allow you to, in effect, cascade the permission you have just granted yourself to all the files and folders on that drive. Tick the box to allow this and Windows should then take care of the rest.If I'm not quite correct here then in my particular case, for example, all my images were stored on my external drive. The top level, or 'parent' folder in which all my pictures could be found was the 'My Pictures' folder and I had created a number of folders and subfolders ('child ' folders) within that folder. The permissions I gave to the Parent folder – My Pictures – were cascaded down through the Child folders.
   
   
9. On completion of the above step I tested the result in Windows Explorer by dragging a few files back and forth between folders and it now worked perfectly - I was now able to move / delete / rename etc all files without now getting the dreaded access denied message. What a sense of relief! This meant that I could now open Bridge normally rather than having to right click it and 'Run As Admistrator' - albeit that is a very useful thing to do until you get the problem sorted as described.

Not being a Mac person, I'm not sure I understand your posts. You have found a correlation between file attributes and the problem, but not the XMP data itself?

What happens if you make a Camera Raw adjustment to a problem image, does this change the problem attribute?

Our best guess on the Windows side is that Bridge is getting its internal database out of sync with reality, although it's difficult to tell for sure because there is no specific error reporting.

I have noted myself that my collection of XMP sidecar files, which have been built up over 4 years, starting with ACR4, often look slightly different, as they have been untouched or updated with different versions of ACR for different adjustments. I don't know if inconsistencies in XMP structure, or a flaw in database management causes the metadata error to start, but in my case I strongly suspect that it is the database management. This because, I can almost guarantee the problem starts with searches and collections, where Bridge must have to build tables of file data from its database.

Kul@, it seems like having 10,000 images per folder would put a heavy strain on the processor to built all the thumbnails especialy if HQ version.  The 4 gigs of ram probably probably does not help either.

I don't know what the effect of the number of files per folder.  My thing is that there more images there are per folder the higher the chance of a cache error when building the thumbnails.  I know in CS3 errors were common and compounded by any switch from the folder before the thumnail building process was finished.

With all that said I try to keep my files around 1,500 per folder and I use embedded thumbs.  Have never experienced a problem, but that could have nothing to do with folder size.

Will be interesting to see if Adobe can ferret out the answer.

I have the same issue (sort of...) My photos are located on a server running Server2008. Usually I can rate the photos but then go to add other metadata (e.g. Keyword or Tag) and get the error message. However, if I wait awhile (not just a few seconds, but can be as long as a minute or so), then I can write the metadata. To me, this likely shows that there is some problem and/or incompatiability (with Windows 7/Server2008) in the Bridge file write caching (i.e. the file is still locked from a previous write attempt when it tries to add the new metadata).

I have a wired 1G LAN and fast computers (including the server) and lots of memory, so I'm sure it is not network/memory lag.

I haven't played with any Sever2008 and/or Windows 7 settings; or for that matter done any work on the write cahing methods employed for Server2008. (I do have write caching enabled on my local harddrives - but I'm assuming any write caching for the server is independent.)

Any thoughts or explanations regarding Bridge writes it's metadata would be appreciated (e.g. does it locally cache changes and do a bulk update?)