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.
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.
Posted 4 years ago
I may have found a workaround. Try closing Bridge before exporting from Lightroom.
I don't have Bridge installed, even, yet I have this problem :-/
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).
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).
I confirm that. I tried to change Faststone for XnView and problem is solved.
John R. Ellis, Champion
"I confirm that. I tried to change Faststone for XnView and problem is solved."
Have you upgraded to CC 2015.1.1 / 6.1.1 or later? This problem was fixed in that release. Do Help > System Info to verify.
Have you upgraded to CC 2015.1.1 / 6.1.1 or later? This problem was fixed in that release. Do Help > System Info to verify.
You're right. Problem was actual for 6.0 version. Sorry for my out-of-date/vague comment.
I have 6.1.1 and during a large export Lightroom still shits down. In fact sometimes I get a blue screen of death
John R. Ellis, Champion
"Problem was actual for 6.0 version."
If you decide to upgrade, do not upgrade to 2015.2.1 / 6.2.1 -- it's plagued with problems, and even Adobe suggests downgrading to 2015.1.1 / 6.1.1 if you encounter serious problems. See here for how to install 2015.1.1: http://www.lightroomqueen.com/how-do-...
If you decide to upgrade, do not upgrade to 2015.2.1 / 6.2.1 -- it's plagued with problems, and even Adobe suggests downgrading to 2015.1.1 / 6.1.1 if you encounter serious problems. See here for how to install 2015.1.1: http://www.lightroomqueen.com/how-do-...
John R. Ellis, Champion
"I have 6.1.1 and during a large export Lightroom still shuts down. In fact sometimes I get a blue screen of death"
Those are much different symptoms than the problem reported and solved in this thread, in which the export completes with a dialog box saying "Some export operations were not performed."
This topic discusses the a more general problem of LR actually crashing (exiting abnormally) when exporting: http://feedback.photoshop.com/photosh.... Adobe is actively working on a next release to fix all the serious issues reported with CC 2015.2 / 6.2.
Those are much different symptoms than the problem reported and solved in this thread, in which the export completes with a dialog box saying "Some export operations were not performed."
This topic discusses the a more general problem of LR actually crashing (exiting abnormally) when exporting: http://feedback.photoshop.com/photosh.... Adobe is actively working on a next release to fix all the serious issues reported with CC 2015.2 / 6.2.
Sorry about that
John R. Ellis, Champion
No need to apologize -- this forum isn't the easiest in which to find things, to say the least.
Thanks for your warning and information.
Victoria Bampton - Lightroom Queen, Champion
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.
Hmmm, perhaps! I shall test this out. Thanks for the suggestion.
John R. Ellis, Champion
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).
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).
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.
John R. Ellis, Champion
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.
What an excellent piece of research John. Thanks for taking the time to do it, and to explain it so clearly.
(Now I understand why I sometimes saw an icon for an exported file appear in the target directory then almost instantly disappear.)
(Now I understand why I sometimes saw an icon for an exported file appear in the target directory then almost instantly disappear.)
Thank you John. You wrote "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". I use AcDsee to view the exported files, and it builds thumbnails on the run as the files are created by Lightroom. AcDsee also sees the swp files (which is shortly after deleted Again by Lightroom). So this effect could be similar to that caused by Bridge.
Steve Sprengel, Champion
John, could you clarify if a watermark is being added to the JPG in either LR 5 or LR 6?
John R. Ellis, Champion
No watermarks were added in the exports that I traced. (I'm tracing exports with watermarks right now. I can reproduce the white-image problem, but the trace seems to indicate it's unrelated to having Bridge or another program open.)
Steve Sprengel, Champion
I would guess everyone has the white-image problem with watermarks or at least I haven't seen anyone say they haven't been able to reproduce it.
Where is the delete for file.jpg before the rename of file.jpg.swp to file.jpg? I don't see that step in your list.
Where is the delete for file.jpg before the rename of file.jpg.swp to file.jpg? I don't see that step in your list.
John R. Ellis, Champion
I believe that the rename call is deleting the destination file (file.jpg) -- I think that's an option on Windows (but not on Unixes).
Steve Sprengel, Champion
Another question, do you have PS-CC / ACR 9? If so does the same thing happen Save Image from within ACR?
John R. Ellis, Champion
I looked at the trace again and here's how the rename really happens:
10. Rename file.jpg to file.tmp
11. Rename file.jpg.swp to file.jpg
12. Delete file.jpg.tmp
10. Rename file.jpg to file.tmp
11. Rename file.jpg.swp to file.jpg
12. Delete file.jpg.tmp
John R. Ellis, Champion
I'll look at PS CC / ACR 9 tomorrow or the day after.
Steve Sprengel, Champion
Do you have Auto Write XMP turned on for either LR 5 or LR 6?
John R. Ellis, Champion
No, it was off.
Rikk Flohr, Official Rep
Thanks for the detailed information, John. I have forwarded this to the team.
John R. Ellis, Champion
Great, thanks.
Julie Kmoch, Sr. Development Manager
Great find, John. Can you tell us what export options you're using? I haven't been able to reproduce this so far.
Julie, I need to do more tests as I think I might be able to reproduce the problem, but definitely not on a per picture basis. My scenario is:
- Open Windows Photo Gallery and view already existing pictures in a folder
- Export pictures to the current folder opened by Windows Photo Gallery or any sub folder of the one Photo Gallery has open.
- Wait for Errors.
I believe you should be able to reproduce it as well, though you will need more than 1 or 2 pictures. I need at least 10 pictures to export for this issue to crop up.
As far as I know, export options don't matter. I am only exporting to Jpg at 90%. Everything else is default settings.
I will do more testing tonight, but after reading this post and running a few informal tests, this issue only seems to happen when I have Photo Gallery open. I think even an explorer window open could also cause this issue, but I am not near as detailed as Mr. Ellis is.
- Open Windows Photo Gallery and view already existing pictures in a folder
- Export pictures to the current folder opened by Windows Photo Gallery or any sub folder of the one Photo Gallery has open.
- Wait for Errors.
I believe you should be able to reproduce it as well, though you will need more than 1 or 2 pictures. I need at least 10 pictures to export for this issue to crop up.
As far as I know, export options don't matter. I am only exporting to Jpg at 90%. Everything else is default settings.
I will do more testing tonight, but after reading this post and running a few informal tests, this issue only seems to happen when I have Photo Gallery open. I think even an explorer window open could also cause this issue, but I am not near as detailed as Mr. Ellis is.
Julie Kmoch, Sr. Development Manager
