Lightroom: Multiple image move operation bug

  • 3
  • Problem
  • Updated 3 years ago
  • Acknowledged
  • (Edited)
Merged

This conversation has been merged. Please reference the main conversation: Lightroom: Moving files, resulted in deleting the files

1. change to Library mode -> Grid view (press 'g')
2. select > 10 images
3. drag and drop images into any folder - notice the image that is highlighted!
4. error dialog "Error While Moving Files" is displayed that the highlighted image was unable to be moved - see screenshot #2
5. manually drag and drop last file into folder :(

This is not 100% reproducible but on my current system (i7, SSD, 12gb RAM) when sorting panoramas into sub-directories, I get this error about 75% of the time. Also on my old system (AMD Phenom x4 w/ 6gb RAM) I would get this error even more frequently.

Win7 x64. Lightroom v3.4.1 (however this bug has been around since at least v2).



Photo of Glenn Bristol

Glenn Bristol

  • 10 Posts
  • 0 Reply Likes

Posted 8 years ago

  • 3
Photo of Lee Jay

Lee Jay

  • 990 Posts
  • 137 Reply Likes
Yep...I've seen this before. Can't seem to nail it down.
Photo of Benjamin Warde

Benjamin Warde, Employee

  • 486 Posts
  • 77 Reply Likes
Hi Glenn,

I'm not able to reproduce this problem. Are you moving photos between folders on the same drive, or between different drives? And just so I'm clear, one of the files fails to move, but then when you dismiss the error message and try moving the photo again, it works?

Thanks,
Ben
Photo of Glenn Bristol

Glenn Bristol

  • 10 Posts
  • 0 Reply Likes
@Ben:
Always moving between the same drive. I tend to shoot several hundred panoramas, with a black frame in-between for fast sorting. Afterwards I manually create folders (because LR ignores importing empty ones) e.g. pan01, pan02, and so on. Then I proceed to move the 8-20 images between black frames into the subsequent folders.

After I dismiss the error dialog, it works fine. That's what makes this so weird, it can't move the _highlighted_ image (of the batch) right this moment (locked by LR?) but immediately after I click the the away I can move it without a hitch. It seems to happen more often when i highlight the first image in the batch and then do the move.

btw i've tried this on an OCZ SSD, USB 3.0 (~80-100 MB/s), USB 2.0 (~20 MB/s) internal SATA II drives in single and RAID 0/1/0+1/1+0/5 (60-180 MB/s) configurations.

@Lee: only 50? I just had it happen around 50 times out of 75 attempts :( it's something i deal with on a weekly, if not daily basis.
Photo of Steve Sprengel

Steve Sprengel, Champion

  • 2673 Posts
  • 348 Reply Likes
I think the file is still being accessed by some other LR thread that can't easily be told to stop mid-access, like computing a preview or comparing metadata or whatever, and if you let it sit a little longer, it'll work more often, and the faster the computer/hard-drive the sooner it's finished, too.

LR has to move the file, any XMP sidecar and possibly the preview so there may be more files and time involved that what would seem obvious. It would be nice if LR would retry the move of any failed files, again, at the end.
Photo of Glenn Bristol

Glenn Bristol

  • 10 Posts
  • 0 Reply Likes
I've thought the same, except speed of my drives hasn't seemed to matter at all. Also I don't shoot previews anymore, which has definitely helped speed things up a bit in general.

+1 to this: "It would be nice if LR would retry the move of any failed files, again, at the end".
Photo of Steve Sprengel

Steve Sprengel, Champion

  • 2673 Posts
  • 348 Reply Likes
Someone else has complained that their image's file-modifacation date gets updated to the current time whenever they click onto an image and have auto-XMP-writing turned on, and this cause Time-Machine to make a new backup copy even though nothing substantive was changed.

I wouldn't be surprised if LR opens the current file in read-write mode in case it needs to update the metadata (perhaps in the XMP file not the main RAW so the file i/o is not a factor) and then goes and checks the database version of the metadata before deciding not to do anything, but for the duration of the checking, the file can't be moved, anywhere. I have this problem when I move whole folder trees at the end of every month, and purposely put LR in Loup view and hide the thumbnail bar or make the thumbnails large so there are fewer, so a minimal number of files are being looked at and I just wait until the Loading... has stopped on the preview and there are no little dots on any thumbnails before trying to move the folders, but I'm dragging folders at the left, not individual images so I don't have to have grid-view or a row of thumbnails selected.
Photo of Glenn Bristol

Glenn Bristol

  • 10 Posts
  • 0 Reply Likes
I share your speculation and experiences!

Moving folders is a whole other bowl of fruit for me that I won't get into. But similarly, to help alleviate slow moving of images (30+), I usually click on some other folder as fast as possible and watch the Moving Images status bar change from 10sec ETA to being complete. If grid view has to shuffle thumbnails as images are moved to/from the folder you're viewing, you might as well go take a coffee break.

Oddly enough, I can't say I've seen this behavior on OS X boxes.
Photo of Benjamin Warde

Benjamin Warde, Employee

  • 486 Posts
  • 77 Reply Likes
Hooray, hooray. I have been able to reproduce this problem, and have entered the issue in our bug database. I should note that I have only been able to reproduce the problem on Windows, not on Mac. If anyone is experiencing this problem on Mac, please let me know.

Thanks,
Ben
Photo of Lambert Wolterbeek

Lambert Wolterbeek

  • 19 Posts
  • 2 Reply Likes
Thanks for this, but the problem still exists in LR4. See my suggestions below.
Photo of Oleksandr Petrenko

Oleksandr Petrenko

  • 18 Posts
  • 1 Reply Like
And in LR 5... Surprisingly, after 2 years :)
Photo of Daniel Rushall

Daniel Rushall

  • 2 Posts
  • 0 Reply Likes
Any developments on this Ben? Am having the same problem and am also on PC
Photo of Steve Sprengel

Steve Sprengel, Champion

  • 2673 Posts
  • 348 Reply Likes
Have you tried things with LR 3.5 RC that was released a couple days ago:
http://labs.adobe.com/
Photo of Jeffrey Tranberry

Jeffrey Tranberry, Sr. Product Manager, Digital Imaging

  • 15586 Posts
  • 2344 Reply Likes
I think you may have meant to say "3.6"
Photo of Benjamin Warde

Benjamin Warde, Employee

  • 486 Posts
  • 77 Reply Likes
I don't expect it to be fixed in 3.6. The bug is still at Open/To Fix in our bug database.

-Ben
Photo of Steve Sprengel

Steve Sprengel, Champion

  • 2673 Posts
  • 348 Reply Likes
I had 3.6 until I re-ordered my sentence and now I can't edit the post. Thanks for correcting things.
Photo of Daniel Rushall

Daniel Rushall

  • 2 Posts
  • 0 Reply Likes
I have only had LR for a week so am still settling in. Shall stick with 3.5 for the moment. Thanks for the update Ben
Photo of Glenn Bristol

Glenn Bristol

  • 10 Posts
  • 0 Reply Likes
3.6 doesn't help, nevermind that it also adds all sorts of annoying quirks. After a couple weeks of frustration I went back to 3.5.
Photo of Lambert Wolterbeek

Lambert Wolterbeek

  • 19 Posts
  • 2 Reply Likes
LR4 still has this problem - it is likely caused by the fact that Lightroom itself is "loading" one of the images that are about to be moved.

In other words, the "load file thread" is agnostic of what the "move file thread" is doing, this causes a locking issue somewhere inside the OS.

Even if you can't fix the bug properly, at least GIVE US THE OPTION TO RETRY THE MOVE. You already have the dialog, how hard can it be to add a "retry" button to it.

Thank you.
Photo of Glenn Bristol

Glenn Bristol

  • 10 Posts
  • 0 Reply Likes
Why can't the move thread just note the error, and retry automatically once or twice with a small (e.g. 250ms) delay between? Even less work and no need for an extra dialog.
Photo of Lambert Wolterbeek

Lambert Wolterbeek

  • 19 Posts
  • 2 Reply Likes
Also fine, but I don't think the problem is that we don't know how to fix it :-)
Photo of TK

TK

  • 531 Posts
  • 120 Reply Likes
Lambert, the issue with the temporary eraser brush keyboard control is affecting me a lot more often and should be infinitely easier to fix.

Has it been fixed yet, after a year of reporting?

No.

I guess you have to adjust your expectations.

BTW, I'm advising against using workarounds / patches (like using an internal repeat try or exposing the problem in the user interface). A bug needs a proper fix. Everything else just creates a big mess over time.
Photo of Lambert Wolterbeek

Lambert Wolterbeek

  • 19 Posts
  • 2 Reply Likes
What can we do to raise Adobe's awareness of our dissatisfaction?

If this doesn't change I would be tempted to use LinkedIn to send "please fix this bug" messages to the actual developers that are listed in the splash window / about box in Lightroom
Photo of Jeffrey Tranberry

Jeffrey Tranberry, Sr. Product Manager, Digital Imaging

  • 15586 Posts
  • 2344 Reply Likes
Thanks. The engineer is aware of the issue and bug is still active. (there's a recent comment in the bug report) It just hasn't risen up to the top of the priority list. I added a comment to the bug report as well pointing to this thread.
Photo of Lambert Wolterbeek

Lambert Wolterbeek

  • 19 Posts
  • 2 Reply Likes
Please, the issue has been reported 9 months ago. It's very annoying and it's easy to fix.

This is typical "low hanging fruit", I would say.
Photo of Oleksandr Petrenko

Oleksandr Petrenko

  • 18 Posts
  • 1 Reply Like
Problem still exists in LightRoom 5... Surprisingly, after 2 years of development :)

Photo of Glenn Bristol

Glenn Bristol

  • 10 Posts
  • 0 Reply Likes
Yes, also confirmed here with latest version. Why do I keep paying for upgrades when they don't fix features that affect me on a nearly daily basis?
Photo of Rory Hill

Rory Hill

  • 244 Posts
  • 38 Reply Likes
Misery loves company. I have been seeing this error as well on Win 7.
Photo of Toby Keane

Toby Keane

  • 2 Posts
  • 1 Reply Like
Just posted this problem in the forums and got a reply and a link to this page. I can't believe that it has been known about for 2 years!! Why is this not fixed yet? Using Lightroom 4. Sort it out please Adobe.
Photo of Bryan Wahrer

Bryan Wahrer

  • 1 Post
  • 0 Reply Likes
I'm a new Lightroom user. Very disapointed in this bug as it appears to have been brought to Adobe's attention years ago and still no fix! I'm not impressed at all.

For what it's worth, I'm running Lightroom 5 on Win7 64bit.
Photo of Oleksandr Petrenko

Oleksandr Petrenko

  • 18 Posts
  • 1 Reply Like
Today in 2nd of June 2014, 21st century, as you may have noticed.

I use Lightroom version 5.4

And I still see this bug.

There is nothing better in this world than stability :)
Photo of Lambert Wolterbeek

Lambert Wolterbeek

  • 19 Posts
  • 2 Reply Likes
Let's all join in celebrating the third anniversity of this fine bug.

https://twitter.com/lambertwm/status/...

And may I recommend that Jeffrey Tranberry (Chief Customer Advocate) be promoted to Senior Master Bug Conservation Officer (First Class).
Photo of Jeffrey Tranberry

Jeffrey Tranberry, Sr. Product Manager, Digital Imaging

  • 15586 Posts
  • 2344 Reply Likes
Official Response
This should be fixed in Lightroom CC/Lightroom 6.
Photo of Glenn Bristol

Glenn Bristol

  • 10 Posts
  • 0 Reply Likes
Thanks for the update Jeffrey!

Unfortunately I have to report that I just had it happen twice in 15 minutes when working on a folder with 1901 NEF files from a D750. I am using the version from April 21st (according to the blog) - Help > About says "2015 Release - Camera Raw 9.0", but I can't find any real version number? Is that the version number now?

I am now updating to the June 15th version, but according to your report, it should have been fixed 2 months ago, so updating probably won't make a difference...
Photo of Olafur Haraldsson

Olafur Haraldsson

  • 22 Posts
  • 2 Reply Likes
I have this same problem with LR CC 2015.1
Photo of Olafur Haraldsson

Olafur Haraldsson

  • 22 Posts
  • 2 Reply Likes
Can this be marked as not solved as I run into this problem few times a day and is driving me crazy.
Photo of Glenn Bristol

Glenn Bristol

  • 10 Posts
  • 0 Reply Likes
I have to report this problem is actually getting worse, and in fact it is now also happening when I try to delete files that files, particularly if I have the file selected.

I guess I have to create a new problem report because they either can't or won't re-open this ticket.
Photo of Lambert Wolterbeek

Lambert Wolterbeek

  • 19 Posts
  • 2 Reply Likes
Which LR version are you using?

It is definitely still an issue LR 5.7.1 - which is what I'm using.

Adobe claims it's fixed in LR6/CC, but I can't confirm.
Photo of John R. Ellis

John R. Ellis, Champion

  • 4562 Posts
  • 1221 Reply Likes
Probably best to open a new ticket, but reference this topic and explain that this bug had been reported solved in LR CC 2015 / 6.
Photo of Glenn Bristol

Glenn Bristol

  • 10 Posts
  • 0 Reply Likes
I'm subscribed to the Creative Cloud Photography package, so I'm always using the latest version - at the moment LR CC 2015.1 Release.
You're probably right John, will do that when I have a bit of time (unless someone else wants to do it ;)
Photo of Oleksandr Petrenko

Oleksandr Petrenko

  • 18 Posts
  • 1 Reply Like
Came here to celebrate the new year. Seen this today again. And yesterday. And many times before.
Photo of John R. Ellis

John R. Ellis, Champion

  • 4567 Posts
  • 1223 Reply Likes
Photo of Oleksandr Petrenko

Oleksandr Petrenko

  • 18 Posts
  • 1 Reply Like
Files are not lost. They just stay where they are with no apparent reason.
Photo of Oleksandr Petrenko

Oleksandr Petrenko

  • 18 Posts
  • 1 Reply Like
Just a reminder, that nothing changes in move department.

Photo of Oleksandr Petrenko

Oleksandr Petrenko

  • 18 Posts
  • 1 Reply Like
Most probably, you just can't care less, but this bug still happens every day.

This conversation is no longer open for comments or replies.