P: Does not export all selected images

[GardenersAssistant]

With Lightroom 6 on Windows 7 I have exactly the same problem as described at http://feedback.photoshop.com/photosh...
with Lightroom 5.4.

I select a number of images and use the Export dialog, exporting to JPEG. After the export is finished I get a dialog box saying "Some export operations were not performed. The file could not be opened ()", and then lists the file names of the images that were not exported.

If I delete the exported JPEGs and try again a different subset of the selected images gets exported. On average around 20 out of 70 selected images don't get exported.

Watching the directory where the images are being exported with a file viewer while the export is in progress I can see that the images that are later shown in the "not exported" dialog box list are in fact being created in the target directory but are quickly deleted.

I have had one example of exporting of a single image failing with exactly the same error message.

I have never had this problem with version 5. I just ran an export of 126 images using Lightroom 5.6 which completed successfully, as has always been the case with version 5 and before that with version 4.

[GardenersAssistant]

I have been getting a lot more failures, including two or three failures in succession trying to export a single image. This is unworkable so I'm going to have to revert to version 5.6.

[Kaur_100]

I got yesterday random error of one totally blank (white) picture when exporting batch of canon raws to jpg.

[FeedbackCommunityMember]

I am having the same problem. It is causing the export to completely give up and not run the portraiture that I have set up to run after the export.

It appears to be completely random. The first time I try the export, 3 files "could not be opened". The second time, 6 files (which are different from the 3 that failed the first time) "could not be opened". It happens to both my raw file and my psd files.

Until this gets fixed, I can't use Lightroom because I need portraiture to be run. I am going to have to revert to an old version.

[Vautrin]

With Lightroom 6 and Windows 8.1 exporting single RAW images to 8-bit TIFF on a specific drive/folder/subfolder I have the same problem SPORADICALLY. I get the error message: "Some export operations were not performed. The file could not be opened ()". But re-doing the export (with no changes) works after several tries. Needlessly to say, this is tremendously frustrating. Re-importing the images doesn't help. Starting a new LR Catalog doesn't help. Temporarily exporting to a folder on the Desktop doesn't help. And, yes, I did install the latest update to LR6.

[FeedbackCommunityMember]

I may have found a workaround. Try closing Bridge before exporting from Lightroom.

[Vautrin]

I tried Amy Johnson's suggestion with 4 example exports and this did work for me. Instead of Bridge, I'm now toggling between Lightroom 6 and Windows Explorer to verify that my export has shown up with a thumbnail in the desired drive/folder/subfolder. Thanks Amy!

Of course that means there is an incompatibility between Bridge (I'm using the CS5 version) and Lightroom 6. Wonderful!

[GardenersAssistant]

"I may have found a workaround. Try closing Bridge before exporting from Lightroom. "

I'm glad you've found a workaround. Unfortunately this won't work for me as I don't use Bridge.

[GardenersAssistant]

Following up on Amy Johnson's discovery I have found that if I have Faststone Image Viewer open at the directory the exported images are going into then I get the problem. If Faststone is not running, or is open at another directory, then I don't get the problem.

I don't get the problem with XnView open at the export directory

I do get the problem if Bridge is running (this is an old, CS2, version of Bridge).

[FeedbackCommunityMember]

Following up some more. Similar to Faststone Image Viewer as Nick Gray reported, I can keep Bridge open but have to move out of the directory that I am exporting to. If I stay in the export directory then the problem occurs.

[FeedbackCommunityMember]

This same thing has been happening to me since installing LR 6 about a week ago.

I normally export master edits as tiff files. Problem is exactly described by original poster.

Bridge seems to be involved as well. Will try closing bridge or moving to another directory when I export.

LR 6 is not done cooking, that's for sure.

[FeedbackCommunityMember]

Yes, with Adobe CS6 Bridge opened in another window, when an export is done to the directory Bridge is monitoring, LR 6 vomits on a few of the file exports. Very consistently, no matter which drive, or directory or file type I'm converting to. Close Bridge, the problem goes away for me.

[johnmca]

I do not have Bridge. Having the same problem as everyone else. It is very annoying.

[johnmca]

export not working for jpeg, or tiff, all the time, may export correctly one out of several tries. This is very annoying. I have un-installed and re installed LR at least three times with the same results. I Do Not have Bridge. The problem with the touch keyboard opening when trying to add keywords has been solved. Did not have this export problem with LR4 or LR5. Now some times when I export , it says cannot open the raw file , I go to where I export them and it is there, This has happened once out of a dozen exports???

[ManiacJoe]

Finally had this happen to me. Win7, LR CC. Attempted to export 40-45 images, 1 did not export.
Bridge not installed.
No image viewers running, nothing monitoring the directory except File Explorer open and showing the output directory.
Never had this problem with LR5.

[FeedbackCommunityMember]

Same here. I didn't find any correlation between the number of the files to be exported and the frequency of this error occurrence: sometimes 100+ will export fine, sometimes one in a group of 10 will fail. Didn't tried yet the suggested above workaround with restarting the application prior to exporting.

[FeedbackCommunityMember]

Same or very similar problem experienced. Started after installing Bridge CC and Lighroom CC on Windows 8.1 system.

When I attempt to export files (as JPEGs) from Lightroom CC, some, but not all files fail to export (error message Lightroom could not open files.)
A second attempt results in DIFFERENT successes and failures.
After repeated attempts to export just the failed files, success is eventually achieved.
I tried optimising Lightroom catalogue, but that did not help.
After reading this discussion, I tried closing Bridge before performing the export and the problem went away.

I noticed another problem with Bridge CC which may or may not be related. That is when using the photo downloader and checking the "Convert to DNG" box. Most, though not all DNG conversions fail. If I run the photo downloader a second time all conversions are successful.

[A_A_S_Schaefer]

Dear support,

in contrary to Lightroom 5.7 I noticed that Lightroom 6.0.1 stops randomly during export service of files with the message 'file could not be opened'. By the way the files which are mentioned could always be opened and accessed, so it's a false error message. I'm using Windows 7 SP1 64 Bit with 8 GB RAM and 500 GB HDD. The number of files during export could be in my case in the range of 300 new files with 12 - 36 MP. Could it be right that file handles are leaked? With export service I mean the publishing service to HDD.

Could you please fix this problem a.s.a.p. since an unsuperviced export is not possible.

Best, Andreas.

[pmw21]

I don't have Bridge installed, even, yet I have this problem 😕

[pmw21]

Support,
I also have the problem described, and see the randomness described.
I do not have Bridge installed, I do not have Faststone installed.
It is a persistent and constant problem, which means that I have to double and triple-check EVERY export, from very small images (600px wide), to large (4000px wide).

Windows 7, LR CC.

[Victoria Bampton LR Queen]

I don't suppose you have a Windows Explorer window opening showing the export folder? It's a long shot but there was a bug a long time back, which I believe was caused by Windows trying to build thumbnails at the same time.

[pmw21]

Hmmm, perhaps! I shall test this out. Thanks for the suggestion.

[jwnielsen]

I also get the "Some export operations were not performed" during export and a list. By running the selected files second time it works. I get 2-3 files wrong in 50-100 pics. I did not notice that in v. 5.7

I use Lightroom 6 stand alone

[johnrellis]

I traced the filesystem calls made by LR 6.0.1, LR 5.7.1, and Bridge during an export on Windows. The trace shows that indeed LR 6 has introduced a bug that will cause file viewers like Bridge and some backup programs to interfere with the export in unpredictable ways.

The trace also shows that LR 6 is writing each exported file twice, causing more than twice as much disk I/O as LR 5. This might account for reports of significantly slower exports. For example, Denni Russell reported that exports were taking 2x longer in LR 6 compared to LR 5: http://feedback.photoshop.com/photosh...

Details

I used Process Monitor to trace the file calls made by LR 6.0.1, LR 5.7.1, and Bridge CC during an export, on Windows 8.1.

Here is what LR 5.7.1 does when exporting "file.jpg":

1. Opens file.jpg for writing
2. Writes file.jpg
3. Closes file.jpg

But LR 6.0.1 adds more steps -- after writing "file.jpg", it reads it back into memory, then writes it out to a temp file "file.jpg.swp", and then renames "file.jpg.swp" back to "file.jpg":

1. Opens file.jpg for writing
2. Writes file.jpg
3. Closes file.jpg
4. Opens file.jpg for read/write access, read share mode
5. Reads file.jpg
6. Closes file.jpg
7. Opens file.jpg.swp for read/write access, read share mode
8. Writes file.jpg.swp (often with a slightly different number of bytes)
9. Close file.jpg.swp
10. Renames file.jpg.swp to file.jpg

There are two problems with this:

Problem 1: LR 6 is writing twice as many bytes to disk as necessary, slowing down exports. I have no facts as to why it is doing this, but as a former developer, I can guess -- an inexperienced programmer is attempting to fix some prior bug and chose an architecturally inept way of doing it. Perhaps the extra writes in steps 7-9 are rewriting the metadata as described in this bug report: http://feedback.photoshop.com/photosh.... The author of Exiftool observed that it appears that the metadata is first written in a more typical fashion, then rewritten in a more atypical fashion.

Problem 2: In step 4, LR 6 tries to reopen the just-written file with read/write access but then proceeds to just read the file. But a file viewer like Bridge may have just opened the file right after step 3 to construct a thumbnail, and if it still has the file open at step 4, LR's reopen for read/write access will fail. When it does, LR thinks some kind of file problem has occurred, deletes "file.jpg", and reports an error to the user.

Bridge is particularly aggressive at monitoring folders for new files so it can create thumbnails. The trace shows it continually trying to open newly created files, every couple of milliseconds.. So it's not surprising that when Bridge is open on the export folder, this problem happens fairly often.

But this problem is not specific to Bridge -- any file viewer, including Windows Explorer, could reasonably try to read the exported file to create a thumbnail, right after step 3. It could also happen with file utilities that are copying files in background (e.g. some kinds of backup programs).

The Fix

A LR architect should review why the file is being written twice instead of just once. Eliminating the second write would avoid the problem and speed up exports. But if it really is necessary to write the file twice, then there are two possible fixes:

a. Keep the file open from step 1 all the way through step 9, and get rid of the gratuitous rename. That way, no other program can access it until it is fully written and closed.

b. Open the file in step 4 for read access/read share mode instead of read/write access. That way, the open won't fail if another program also has the file open for reading. This fix is suboptimal, because the other program will read bytes from the file that aren't the "final" bytes (which won't be written until step 8).

[FeedbackCommunityMember]

Thank you John for this research! I hope Adobe sees it. I wonder if they're seeing this thread at all since they haven't responded yet.

[johnrellis]

Adobe says they try to read everything here, though they reply much less frequently. In addition, there are moderators who try to bubble up issues to Adobe as well.