Lightroom: "Date Modified" dates is updated on import of photos from a volume other than the destination volume

  • 2
  • Problem
  • Updated 7 years ago
  • (Edited)
If I import photos from a volume that is different from the destination folder's volume, the Date Modified field value for the photos is update to the current date/time. This shows in the Finder's Date Modified column of file details. This is a behavior that the Finder itself does not do. I can copy files including photos from one volume to another and the Date Modified does not change. Since LR runs under the mantra of not "touching" the original photos, this is a flaw. I don't want that date modified upon import from another volume.

I'm on Mac OSX 10.6.x (the latest) and using Lightroom 3.x (latest). I have verified that if photos start and end on the same volume it leaves the date alone. It's only when the locations differ.
Photo of Teaman

Teaman

  • 6 Posts
  • 1 Reply Like
  • frustrated

Posted 7 years ago

  • 2
Photo of Steve Sprengel

Steve Sprengel, Champion

  • 2589 Posts
  • 323 Reply Likes
When you copy a file with any program, the date created and date modified and date accessed of the destination are always the current time. This is because the destination file is, indeed, new. The OS is doing this, not the program. You can verify this by listing the folder contents as the file copy is underway. After the copy is complete, the OS-supplied copy operation in Finder resets the Modified date back to the date of the source file, but it's not that LR is doing something deliberate to update the date to the current time, it already is, the Finder copy function is just doing something extra after the copy operation is complete.

So the proper way to characterize LR's behavior is that LR is not resetting the Modified date at the end of a Copy operation and it's basically a feature request that you'd like it to do something similar to Finder.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 372 Reply Likes
'Date modified' is stored in the directory, not the file, so strictly speaking, the file is not being altered (no mantra violation). 'Tis a curious behavioral difference, but why is it causing a problem for you? - you may need to make a case in order for this to be remedied...
Photo of Teaman

Teaman

  • 6 Posts
  • 1 Reply Like
Thanks guys for the explanations.
I use the Date Modified (the default Finder date column) to help me identify when a photo was taken without having to dig into some app to get at the metadata values such as opening LR and waiting the 2 mins for it to open. I guess I could ask the question why would you want to view the Date Modified column for any document. It's a piece of information that is used to identify and organize with.

Given that Apple felt it important enough to reset the moved file's date back to what it was on the source, why would it not be a good idea for LR to do the same and be consistent?... not for the sake of being just consistent but because it causes less confusion as I experienced. Maybe I'm the first person on the planet to notice this but I find it disturbing. When you consider it, just because a file moves is "new" to a volume it hasn't been on before does not mean that file has been modified internal to itself, has it? It's environment may be changed but that external to the file. The file is the same, in fact EXACTLY the same as it was on the source location.

So I think Apple has it right. A moved file should retain it's Date Modified value until some app opens and changes it. In this case no app has. From a user's perspective, changing volume locations should be transparent. It's like a different folder. Can you imagine the confusion that would result if this behavior occurred on any file you moved from folder A to folder B? Folders are simply representing a collection of files. Volumes are an extension of that concept but introduces a physical barrier that is crossed. But to the user that should be transparent. The fact that the h/w is now different for a moved file should only matter to a user when needing to transport the data or the volume is reaching capacity.

I hope this helps you realize why I think this is a flaw that should be corrected in LR.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 372 Reply Likes
What type of files are they? i.e. what is the extension? are you converting to DNG?
Photo of patrik

patrik

  • 2 Posts
  • 0 Reply Likes
I'm with you a 100%. Date Modified should be preserved. This should be considered a bug i Lightroom on OS X.
Photo of patrik

patrik

  • 2 Posts
  • 0 Reply Likes
Looking back at my photos from the beging of February this year, I didn't have this problem. The Date Modified timestamp is correct. So there is a recent change i Lightroom that's causing this.
Photo of Geoff Walker

Geoff Walker, Champion

  • 214 Posts
  • 42 Reply Likes
I can see the logic in this. Interesting, thanks for raising the subject.
Photo of Jim Wilde

Jim Wilde

  • 136 Posts
  • 26 Reply Likes
And yet on Windows 7 it just works the way one would expect....Date Modified is retained when importing from one hard drive using Copy to create a new version on a different hard drive.
Photo of John R. Ellis

John R. Ellis, Champion

  • 3378 Posts
  • 849 Reply Likes
I think the Windows behavior results from LR using a standard Windows API function for copying files, and that function preserves Date Modified. In general, I think it's likely that LR simply uses whatever OS API is most convenient for copying files -- the Windows API happens to preserve the date, while the Mac API doesn't.

I'm not arguing against LR explicitly preserving the date, just explaining the current behavior.
Photo of David Pope

David Pope

  • 8 Posts
  • 0 Reply Likes
Just found this thread; I'm having a similar problem where Date Modified is being "touched" just by viewing JPG files that have been in my database for years (OSX 10.6.8, LR3.4.1).

http://tinyurl.com/3slypgn

-- David