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