Lightroom: Changes creation date of image files

  • 10
  • Problem
  • Updated 8 months ago
  • (Edited)
Lightroom 5.5 running on Macintosh Mavericks 10.9.3 clobbers the creation date when modifying a file.

I did the following test: I added a folder of jpgs to Lightroom, and then I added a keyword to all of them. I have "Automatically write changes into XMP" set in my Lightroom catalog. After changing the keyword, the creation date is now set as the same as the modification date which is incorrect behavior (and an important loss of metadata).

It is not necessary to change the creation date to change tags, for instance the command line

% exiftool -overwrite_original_in_place -subject+="Jane Eyre" image.jpg

does not change the creation date, but only the modification date.

See https://forums.adobe.com/thread/1192949 for other reports of this bug, now over 1 year ago.
Photo of Alan Harper

Alan Harper

  • 424 Posts
  • 84 Reply Likes

Posted 4 years ago

  • 10
Photo of Steve Sprengel

Steve Sprengel, Champion

  • 2647 Posts
  • 337 Reply Likes
Lightroom is doing the safe thing. It is creating a new temporary file, writing all the updated JPG file information to it including XMP and image data to that new file, then removing the original and renaming the temp to the original name. This would indeed change the creation date because the updated file is a new file.

The unsafe "overwrite-original" way would leave the JPG without some or all of it's image data if the power failed or a bug aborted the program in the middle of the file-write operation, or even there was a bad sector on the disk, instead of doing the new/delete/rename process, where the worst that happens is the XMP doesn't get written and there is a temporary file left over in the folder, both of which LR can recover the next time it's processing files from that folder.

Maybe modern operating-systems use a journaled file system that's really a database and always double-buffer file changes, but some devices that aren't the internal drives, such as file-servers and flash drives might not allow such operations and you'd have corruption occurring.
Photo of Philip King

Philip King

  • 18 Posts
  • 3 Reply Likes
On the other hand, Adobe’s Bridge manages to embed metadata into an image file without changing the creation date, so there’s disagreement between two Adobe products.

Given the choice, I would prefer to leave the file creation date untouched and take the infinitesimal risk of file corruption occurring while writing to metadata.

This is the main block on me embracing Lightroom. I have thousands of image files going back to the late 1990s, all with valid and intact creation dates which can be used as search constraints in the finder. If I bring these files under Lightroom’s influence then I lose this continuity of essential data.
Photo of Alan Harper

Alan Harper

  • 418 Posts
  • 82 Reply Likes
Philip—if you are willing to rename all your files, you could use A Better Finder Rename 9 (one of my favorite utilities) to add the creation date to your file names. Not a real solution, but a good work-around while we wait for Adobe to address this bug. (And, FWIW, there is at least one other program with a similar bug, and that developer claims that the problem is part of a bug w/in Apple's OS code).

When I take photos, I rename every photo to start with the date and time that they were taken in the form YYYY-MM-DD HH-MM-SS, followed by the file name given by the camera (e.g. 2014-06-30 07-13-48 IMG_1234.CR2). That way when I sort by name, the files are sorted chronologically even if they were taken on different cameras. Unfortunately, I have not done this for my slide scans, which is where this loss of metadata (the date scanned) does cause me problems.
Photo of Reinard Schmitz

Reinard Schmitz

  • 55 Posts
  • 7 Reply Likes
This is a nice way as long as you don't leave the time zone. Things get cluttered if you use an iPhone and a normal camera in these days, when time zone changes several times. You then have to look for those photos to rename by hand to reflect this to get the right time line. If you change the EXIF date and time first and rename with these data you are fine in both cases, but it takes a lot of work. Anyway, using LR you have to copy EXIF data to file creation date/time from time to time in order to preserve you time line given by creation date and time.
Photo of GEGJr

GEGJr

  • 64 Posts
  • 1 Reply Like
Not just an Apple OS problem!
Photo of Alan Harper

Alan Harper

  • 424 Posts
  • 84 Reply Likes
Steve, you are so authoritative sounding. Do you know that what you are saying is true, or is it just your best guess to justify what is going on? (I mean, are you privy to the actual internals of Lightroom's code?)

Even if you are correct, there is no reason that Lightroom would have to work this way. When one copies a file from one volume to another in the Finder, or even duplicates a file within a volume, the new file picks up the original creation date of the old copy. (Go ahead, try it). There are calls in the operating system that allow you to set the creation date after you create a new file.

Sorry, but in my mind (and others, see the discussion I referenced) this remains a bug.
Photo of Steve Sprengel

Steve Sprengel, Champion

  • 2647 Posts
  • 337 Reply Likes
If I copy/paste some image files from an existing folder to a new folder using Windows Explorer on Windows 8.1, the Modified Date remains the same as the original files, but the Create Date of the newly copied files is Today.
Photo of Alan Harper

Alan Harper

  • 424 Posts
  • 84 Reply Likes
Well, Steve, Windows is actually being consistent, even if different than Mac OS (whose behavior I prefer in this case). I guess the next test is whether your favorite word processor or other productivity program changes the creation date every time you edit a file. And if it does not, does that make you worried that you will lose the file due to a possible corruption during saving?
Photo of Steve Sprengel

Steve Sprengel, Champion

  • 2647 Posts
  • 337 Reply Likes
With a word-processor the file is still open during and after the save so I can save it, again, if there is an issue.

With LR writing XMP changes, LR is in control over the entire process and the user doesn't get to retry.

I trust myself with my document saving more than I trust LR doing it in the background with what could be many, many images.
Photo of Alan Harper

Alan Harper

  • 424 Posts
  • 84 Reply Likes
Hopefully someone from Adobe will weigh in on this issue.
Photo of Alan Harper

Alan Harper

  • 424 Posts
  • 84 Reply Likes
Oh, hey, Steve, I forgot. If you have "Automatically write changes into xmp" set in one of your catalogs, can you confirm if this is a Mac-only issue or is true for both versions of LR? The discussion I referenced above suggests that it is a Mac-only issue, but it wasn't completely clear.
Photo of Steve Sprengel

Steve Sprengel, Champion

  • 2647 Posts
  • 337 Reply Likes
I do have Auto-Write-XMP on, but I almost always work with raw files so they have a separate XMP sidecar file; however, I happened to work on a couple 5-year-old JPGs and the creation date of them didn't change when metadata was written last night--it said LR 5.5 so it had to be last night's changes. However, what I did notice was that there was a few hundred bytes (it seemed) of blanks before the final closing XMP tag in the XMP packet area in the header of the JPG, so I think the reason LR didn't create a new file was that there was enough extra space in the file for it to write any metadata changes in place, so the entire file didn't need rewritten.

The very first time XMP data is written to a JPG, the file would need to be extended and at that point I'd guess a new file would be created, but until I run across one of those, I don't know for sure.
Photo of Steve Sprengel

Steve Sprengel, Champion

  • 2647 Posts
  • 337 Reply Likes
Your feature request boils down to asking Adobe to always overwrite JPGs unsafely rather than the safe create-temp/delete/rename-temp process that they apparently use so the creation-date doesn't get updated, or use OS-level functions to adjust the creation date of the newly-safely-created JPG to have the same creation date as the JPG that was just replaced.

What is the benefit of doing this to the users? If Adobe is going to prioritize such a feature request then they'll need some way to weigh the resource costs to effect such a change with the benefits to the user base.
Photo of Philip King

Philip King

  • 18 Posts
  • 3 Reply Likes
When a file is modified, such as by adding metadata, then it is the modification date which should be updated, not the creation date. The creation date should be the date which a usual user would understand as the date the file was created — not rewritten, not moved, not modified, but created.

My image files (mentioned before, going back to late 1990s) have been moved from drive to drive and probably restored from backup at least once, yet they retain their creation date regardless that the data has been rewritten, even onto differently formatted drives. Some have had icons rebuilt but still retain their creation date.

I’m not really bothered about the technical innards of the file, that’s Adobe’s business. What I want is the normally expected behaviour that modification of a file doesn’t change the creation date. Photoshop doesn’t do it to PSDs, InDesign doesn’t do it to INDDs, Illustrator doesn’t do it, neither does Bridge. Just Lightroom, as far as I can tell.
Photo of GEGJr

GEGJr

  • 64 Posts
  • 1 Reply Like
Although technically not an image database manager, BreezeBrowser by Breezesys doesn't overwrite the creation date when adding keywords or comments or any user specific information including renaming. I think it's ludicrous how Adobe has completely ignored the issue and almost criminal how Adobe representatives have all but called me a liar every time I report and complain about the issue. I have had to resort to renaming my files on import to include the creation date thus limiting the available characters for giving a meaningful name for identification.
Photo of Brian M.

Brian M.

  • 21 Posts
  • 2 Reply Likes
Note from a year later: LR 6 (mac, Stand-alone) still does it. (OSX 10.10.3)

For those tempted to reply with Explorer based answers, please be aware that this is a Mac issue. Windows boxes have a different file system. It's behaviors are totally irrelevant to this problem. Equally, pedantic discussions about the nature of what constitutes a "New" file, while philosophically interesting, are not helpful. The Mac file system does in fact create a new file whenever it updates a file, but is smart enough to retain the creation date information from the 'original' file, whatever that was. The fact that LR corrupts this information is due to sloppy coding in LR, not any sort of file system behavior. Requiring that it be corrected does not in any way require them to change the nature of how the files are saved, it simply requires that they stop interfering with the proper operation of the file system. If you'd leave it alone, it'd probably handle the job properly.

The problem is that LR is corrupting the "creation date" field of the file's info, outside of the image metadata. It's resetting that date to whatever date the image was first imported into LR, rather than the original creation date of the image itself.

I've got image files going back to the early 90s, long before there was any thought given to metadata. My naming conventions from back then never thought they'd need to redundantly back up such basic information as origination date. The only way I have to keep track of which version came first is that information. If LR corrupts it, I'm screwed. Which is why those images are not referenced in LR. This is a *very* serious problem for any user with large, or long-standing professional archives.
What I require is that the images I created in 1992, with Photoshop 2.0 retain their original creation dates. Without question. The fact that this glitch exists at all, let alone that it's survived at least 2 alpha releases and several years of user complaints indicates a troubling lack of concern about the basics of file handling.

-Brian
Photo of Alan Harper

Alan Harper

  • 424 Posts
  • 84 Reply Likes
Hear, hear, Brian. I agree completely.

Just one comment though. As far as I can tell, this happens when Lightroom needs to make the file bigger to add metadata. If the original file was saved in a way that there was no room to add metadata, then Lightroom will change the create date to the date that the image was first imported into Lightroom. More normally though, in my experience, the date will change at some later time, when Lightroom finds that it doesn't have room in the file to add changed metadata. Among other things, this means that you can never know when you are going to lose this information, and it is impossible to guard against.

From comments in this thread, it appears to be a Macintosh-only bug. And given the lack of comments from Adobe, I suspect that the only solution is to abandon Lightroom or switch to Windows.
Photo of Brian M.

Brian M.

  • 21 Posts
  • 2 Reply Likes
Interesting. I've just tested it on some dummy data, to see what happened on import, I didn't then stay with the dummy files long enough to observe what you report, but it makes sense. The formats back then didn't have any provision for metadata, or if they did, it wasn't implemented in any meaningful way.
They really should fix the issue, it's not *that* hard to record the original file date, update the file, and then re-jigger the origination date.
That being said, I'm working on resurrecting my unix long enough to see about writing a script for exiftool to just do a batch "grab the file date, and stuff it into the exif creation date". I do that once, and I should be good. Don't hold your breath, but if I ever get it to where I'm happy with it, I'll post the info here.
-Brian
Photo of Alan Harper

Alan Harper

  • 424 Posts
  • 84 Reply Likes
Brian. I can send you a script that does something completely else, but has building blocks that you could use. adobe@alanharper.com
Photo of Albina Zaripova

Albina Zaripova

  • 2 Posts
  • 2 Reply Likes
I am experiencing this bug in LR for many years.

I have lots of files that don't contain any capture time in a metadata part (for instance, JPEG-photos from some old mobile phones). Therefore the file creation date becomes the only source for knowing when the photo was shot.

As a user I don't need to know about those weird things that LR does when it updates and rewrites a file. It's just not my business. From my, user's sight, LR simply corrupts this *important* information without no valid reason.

Excuse me for my emotions, but after so many years this behavior is inexcusably.
Photo of Philip King

Philip King

  • 18 Posts
  • 3 Reply Likes
It's very frustrating and the sole reason I don't use Lightroom and won't use it until this is fixed.
Photo of Orjan Ellingvag

Orjan Ellingvag

  • 7 Posts
  • 2 Reply Likes
Notice with the new Lightroom CC 2015 the modified date is changed as the files are uploaded/synced with the Adobe Lightroom Mobile.

It's a problem. I use the last modified date to find the most current version of the image ( I often have different versions, due to captions in different languages etc).

The "write date or time changes into propietary raw files" is unchecked. The catalog is set to automatically write metadata changes into files.

This seems to be a new "feature" or bug,as no changes in the modified date appears in Lightroom 5.x appears unless I do changes to the files (caption,flagging,rating,adjustments etc).

There should not be any reason for the files to have their modified date changed only because their upload status in LR mobile have changed. Use a log file instead.

LR CC 2015, win7prox64, 32gb ram
Photo of John R. Ellis

John R. Ellis, Champion

  • 3676 Posts
  • 961 Reply Likes
I'm not able to reproduce this. Can you provide a more detailed step-by-step recipe?
Photo of Reinard Schmitz

Reinard Schmitz

  • 55 Posts
  • 7 Reply Likes
Whatever opinions you have: if a file is modified, in which manner ever, only the modified date has to be changed. The creation date is very important for archiving purposes and for time lines of photos when you are travelling for a long time: you want to see them in a row with time in the finder/explorer. The counter in the file name can't be a sort criterion if you use differ cameras on your way.

That's why I normally don't use the adding feature in LR. And if, I have to copy EXIF time and date back to to system time and date from time to time in this directories I made changes I'd additions.

It's Adobe who has to remove this bug (as many others they know for years!). Or add a switch somewhere ("preserve creation date y/n").
Photo of John R. Ellis

John R. Ellis, Champion

  • 3724 Posts
  • 974 Reply Likes
Note that in Windows File Explorer, you can sort pics by capture time by doing View > Sort By > Date Taken. Unfortunately, Mac Finder is much more limited in its capabilities and doesn't off that ability.
Photo of John R. Ellis

John R. Ellis, Champion

  • 3724 Posts
  • 974 Reply Likes
Photo software generally ignores the operating system's file-created and -modified dates, and when it doesn't ignore them, it generally treats them in non-standard ways that vary from program to program. Instead of relying on the operating system's file dates, the photo industry has defined metadata fields with all sorts of photo-specific dates: date/time of capture (when the shutter was pressed), date/time of digitization (when a film or print image was scanned digitally), date/time photo software last changed the image or metadata, date/time of GPS location. While some photo software will attempt to maintain the file-created and -modified dates, many programs and Web services won't (including, but not limited, to LR). In addition, many file utilities will not always preserve the created and modified dates as you move, copy, backup, and restore files.

Thus, I highly recommend that if you care about photo dates/times (as I do), then regardless of which photo software you use, you store the capture dates in the photos' industry-standard metadata using the tools provided by LR and other photo software. That way, as you migrate from program to program over the years, you're more likely to preserve that important metadata.

For old pictures and scans without that metadata, when you first import them into LR, LR will assume the capture time is the file modified time. You can cause LR to write the metadata capture date back to the file by selecting it and doing Metadata > Edit Capture Time, clicking OK, and then doing Metadata > Save Metadata To File. You can do that in batch -- select all your old pics, do Metadata > Edit Capture Time, click OK, do Metadata > Save Metadata To File. LR will set each file's capture time to its modified time. If instead you want to set the captured time to the file create time, select that option in the Edit Capture Time window before clicking OK. But beware that many Windows and Mac file utilities may not preserve create time, even if they preserve modified time, so your files' create times may be bogus. And of course make sure your backups are current and valid before you do any new file procedure with which you're not familiar.
Photo of GEGJr

GEGJr

  • 64 Posts
  • 1 Reply Like
Pure balderdash and poppycock! Shouldn't be happening plain and simple. Until I started using LR 3 never had this problem. In fact I didn't realize LR was even changing the creation date until I went to look for old images shot pre-LR that I moved to my new image archive location using LR to keep track of the files. I have had a dickens of a time trying to fix the problem. Many of the images are so old I have forgotten exactly when they were shot. I've even noticed LR sometimes changes keywords on previously selected images after deselecting all then selecting new images to add or change keywording. LR representatives even deny this behaviour even though I've documented it several times.
Photo of Reinard Schmitz

Reinard Schmitz

  • 55 Posts
  • 7 Reply Likes
You all describe the bug Adobe has to correct very clearly: they just have to treat OS data as they are intended to be treated. That's all I want.
Photo of John R. Ellis

John R. Ellis, Champion

  • 3724 Posts
  • 974 Reply Likes
“treat OS data as they are intended to be treated”

That’s the crux of the issue – what you intend is not what some operating systems and many applications intend. In general, there is no widely accepted standard across Windows and Mac applications for how to treat a file’s Date Created.

Some examples:

- Mac Finder preserves Date Created when a file is copied, but Windows File Explorer does not. So you better not use File Explorer (or many other Windows file utilities) to make backup copies of your files if you expect Date Created to be preserved.

- Windows File Explorer doesn't preserve Date Created when you use it to change a pic's metadata (e.g. its Title).

- By default on Windows, when any application copies a file, Date Created is not preserved. Some applications take extra steps to preserve it, some don't. It was for this reason that Adobe changed LR to use an imported video file's Date Modified as the capture date rather than Date Created (when it wasn't able to read the video's metadata) -- on Windows, the Date Modified was much more likely to reflect when the video was taken rather than Date Created.

- Mac and Windows Picasa does not preserve Date Created when you edit a pic or change its metadata.

- Mac iPhoto doesn't preserve Date Created when you edit a pic or change its metadata.

Given that the photo industry has standardized on recording date/times in a photo's metadata, not in the operating system's file date/times, and given that there is no widely accepted practice for how applications treat file Date Created, in my opinion it's not very likely Adobe will change LR's current behavior.
Photo of Reinard Schmitz

Reinard Schmitz

  • 55 Posts
  • 7 Reply Likes
That's why I do the management by hand by copying the EXIF time and date from time to time to preserve my timelines in finder...
Photo of Brian M.

Brian M.

  • 21 Posts
  • 2 Reply Likes
My problem is that I've got tens of thousands of images, going back to Photoshop 2, in 1992, on a Mac. No way I'm going to go thru and hand-enter all the creation dates.
Bigger problem is that I'd have to either write down, or frankenstein some way to grab a directory's worth of creation dates *before* I let LR touch them, because it corrupts the creation date when it adds the file to the catalog. So asking LR to write the file date to the metadata is a null option, because LR has already corrupted the data.
I've got a friend working on a way to script EXIFtool to grab the file date, and crossload that to the metadata creation date automagically. That may help. I'll post it when/if it ever gets done.

Another issue is that a lot of those old files just don't have the resource structure for modern metadata.

I'd be happy if Adobe just came out with a little applet that only did that: take current file creation date, and crossload it into the metadata creation date. Dump a whole directory on it, and go to town.

I'd like to see LR fixed, but what I really care about is getting my files cataloged, in the right order, with the original dates. However that gets done is good enough.

-Brian