P: Does not export all selected images

Impressive!

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.

John, I'll file a bug to have someone take a closer look. Thank you for the depth of your research on this.

To further increase confidence in my observations, I traced LR 5.7.1 and LR 6.0.1 on OS X 10.10.3 using the "dtruss" tool. I added these traces and details to the Dropbox folder linked above.

As on Windows, Mac LR 5 writes exported .jpgs with a single pass, while Mac LR 6 uses three passes.

Julie, I redid the traces of exports in LR 4.4.1, LR 5.7.1, and LR CC 2015.0.1, and Save Image in PS CC 2014 / ACR 9.0 (all on Windows 8.1). I observed the same things as in my previous report and confirmed some of my guesses about the metadata.

I've uploaded a folder of all my traces, detailed notes on how they were made, and Exiftool dumps:

https://dl.dropboxusercontent.com/u/2...

I encourage your engineers (and anyone else) to examine these in detail, and I'd be glad to confer with any interested party on- or off-line.

Observations

- LR 4, LR 5, and ACR 9 use a single pass to export a .jpg.

- LR 6 uses three passes: 1) write the .jpg, 2) read the .jpg back into memory, 3) write .jpg.swp and rename to .jpg.

- The first pass writes all of the metadata, using a typical layout for the EXIF IFDs (as used by LR 4 and 5).

- The second pass opens the file for read/write access even though it is just going to read the file into memory.

- The third pass rewrites all of the metadata, using the problematic atypical layout described in this bug report:

http://feedback.photoshop.com/photosh...

This pass changes the Region Area fields, the XMP History fields, and Instance ID field but no other metadata field.

The LR exports used the exact same export preset, with these options: Export To: Specific folder, Image Format: JPEG, Quality: 60, Color Space: sRGB, Metadata: Include All Metadata (no other options checked). The preset is included in the folder above.

Fixes

As I described above, there are three possible fixes that would guarantee no conflict with Bridge, other file viewers, backup programs, and utilities like Dropbox:

- Use a single pass to write the file, as LR 4 and 5 do, ACR 9 does, and nearly every other program does. Why were the additional passes added to LR 6? Architecturally, there is no need for the inefficiency of additional passes. (Perhaps the additional passes were added by the engineers implementing face recognition, since the only non-history fields changed on the third pass are the Region Area fields.)

- Keep the file open throughout all three passes. (Don't close the file at the end of the first and second passes, but instead seek back to the beginning.)

- In the second pass, open the file for read access rather than read/write access. Then there would be no sharing violation as the other programs and LR both read the file concurrently. This may be the easiest patch but is least desirable, since it still allows other programs to read stale metadata from the file (as they're doing now).

The latter two fixes are just very simple patches to the current inefficient multi-pass design, but at least they ensure a lack of conflict with other programs.

After a quick check with some of the engineers, the behavior John Ellis reports is actually expected and longstanding. I'm not sure why it appears different in 5, other than possibly having different export options enabled?

The temp file dance that John describes is intended to preserve the original in case something goes wrong with the file update. Which we find often does on Windows.

We can't write to a Windows file that another process has opened for reading. Export is done in two passes: first we write the pixels, then update the metadata. If another process, like Bridge, Windows Explorer's thumbnailing, or search indexing, grabs hold of the file before we finish the metadata write phase, we'll try our safe-save 10 times before giving up. Our best theory is that the gap between these two stages may have increased slightly, giving other processes a foothold to steal the file from us.

Closing Bridge or other apps that will be watching these fresh exports should indeed help. We'll look at other ways to stretch out the retries to work around it.

Great find, John. Can you tell us what export options you're using? I haven't been able to reproduce this so far.

Great, thanks.

Thanks for the detailed information, John. I have forwarded this to the team.

No, it was off.