Skip to main content
Adobe Photoshop Family

474 Messages

 • 

10.5K Points

Mon, Jun 30, 2014 4:49 AM

Lightroom Classic: Changes creation date of image files

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.jpgdoes 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.

Responses

2.6K Messages

 • 

33.7K Points

6 years ago

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.

1 Message

 • 

62 Points

This is a mac problem, so please step back to give smart advice here as a windows user.
And I don't care what is happening under the engine hood of LR, I just want the data which was there (File created) staying there.

49 Messages

 • 

756 Points

6 years ago

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.

474 Messages

 • 

10.5K Points

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.

67 Messages

 • 

950 Points

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.

118 Messages

 • 

1.5K Points

Not just an Apple OS problem!

474 Messages

 • 

10.5K Points

6 years ago

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.

2.6K Messages

 • 

33.7K Points

6 years ago

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.

474 Messages

 • 

10.5K Points

6 years ago

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?

2.6K Messages

 • 

33.7K Points

6 years ago

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.

474 Messages

 • 

10.5K Points

6 years ago

Hopefully someone from Adobe will weigh in on this issue.

474 Messages

 • 

10.5K Points

6 years ago

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.

2.6K Messages

 • 

33.7K Points

6 years ago

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.

2.6K Messages

 • 

33.7K Points

6 years ago

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.

49 Messages

 • 

756 Points

6 years ago

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.

118 Messages

 • 

1.5K Points

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.

21 Messages

 • 

300 Points

5 years ago

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

474 Messages

 • 

10.5K Points

5 years ago

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.

21 Messages

 • 

300 Points

5 years ago

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

474 Messages

 • 

10.5K Points

5 years ago

Brian. I can send you a script that does something completely else, but has building blocks that you could use. adobe@alanharper.com