Lightroom: Changes creation date of image files

  • 10
  • Problem
  • Updated 1 year 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

  • 458 Posts
  • 94 Reply Likes

Posted 5 years ago

  • 10
Photo of Reinard Schmitz

Reinard Schmitz

  • 65 Posts
  • 8 Reply Likes
@Brian: Have a look at "BETTER FINDER RENAME 9" and/or "ExifChanger", they may help you.
Photo of Alan Harper

Alan Harper

  • 458 Posts
  • 94 Reply Likes
Photo of John R. Ellis

John R. Ellis, Champion

  • 4710 Posts
  • 1277 Reply Likes
Brian M wrote, "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."

Actually, if you have pics that are missing their metadata capture-time field, it's quite straightforward in LR (though not well documented) to batch-set their metadata capture time to either their Date Modified or file Date Created:

1. Make a backup of your catalog and photos (using a backup program you know 100% preserves file Date Created and file Date Modified).

2. Uncheck the option Catalog Settings > Metadata > Automatically Write Changes Into XMP. This stops LR from automatically updating metadata in the files (and changing their file dates).

3. Import a batch of photos. If the pics are on a local volume, you can use either the Add or Move options; but if they're on a network volume, it's safest to use Add, since not all network volumes on Windows will properly preserve file Date Created when an application does a move (don't know about Mac).

4. Select all of the imported photos.

5. Do Metadata > Edit Capture Time.

6. If you want to use the files' Date Modified as the metadata capture time, select the option Adjust To A Specified Date And Time. If you want to use the files' Date Created, select the option Change To File's Creation Date. Verify that Corrected Time matches the file Date Created / Modified as shown by Finder / File Explorer for the pic shown in the dialog. Click Change All. Note that this will not set all the pics to the same exact time -- it will set each pic to its own file Date Modified or Date Created. (The words at the top of the dialog attempt to explain this, but it's still confusing.)

Of course, test out this procedure with a few pics first to make sure you understand each of the steps.
Photo of Robert Frost

Robert Frost

  • 435 Posts
  • 73 Reply Likes
Surely the crux of this problem is the fact that the filesystem's create date, modified date and accessed date are just that - they are part of the file system, stored in the file system, and are not stored in the actual file. They are simply a means of the file sytem keeping track of files, and different file systems do this in different ways, and with different success. They are what you see in File Explorer or equivalent.

The only dates stored in the raw images normally are the Exif capture date, digitised date, and modified date set by the camera when you take the images.

So if you copy an image to a different folder, the file system will give the copy a new create date - the date the copy was made. But the Exif dates remain the same in the copy of the image.

So there is little point in relying on the filesystems dates for anything to do with images.

Lightroom's dates are a third set of dates, part EXif part LR only, stored in the catalog or in xmp sidecars (raw files) or in xmp in the image (jpgs, etc,).

Not surprising we get confused at times!!

Someone will no doubt tell me I'm confused!!!!

Bob Frost
Photo of Reinard Schmitz

Reinard Schmitz

  • 65 Posts
  • 8 Reply Likes
>> So there is little point in relying on the filesystems dates for anything to do with images.

So, why you think the programmers of UNIX invented a file creation date? And why a photo is not a file like any other?
Photo of Alan Harper

Alan Harper

  • 458 Posts
  • 94 Reply Likes
Sorry Bob. You are confused. Most programs for the Mac (including Finder and Path Finder) will conserve the create date when you copy a file. Also most programs will conserve the create date when you modify a file. After all, this is what a "create date" means, the date that the file was created. The modify date is, duh, the date that the file was last modified.

Our gripe is that Lightroom is one of the programs that does not follow what would seem to be very simple guidelines—if modify a file, don't change the create date.

Given that this bug, and it is a bug, is in Lightroom for Macintosh, and given that Adobe seems to have no interest in fixing it, I agree completely with all your other comments.

Like most bugs, the issue is not that the problem cannot be worked around, it is that it creates so many special cases that you make mistakes, lose time and don't make progress in your goals.

A
Photo of Robert Frost

Robert Frost

  • 435 Posts
  • 73 Reply Likes
Confusion reigns! As far as the MS OS file system is concerned, when you copy a file you create a new file (there are now two files where there was one!) and it is given a new create date by the file system. That is what it is meant to do. The file system does not care a jot about the contents of the two files being the same as far as create date is concerned.
Photo of Brian M.

Brian M.

  • 21 Posts
  • 2 Reply Likes
Yes, but we're talking about the *MAC* file system. Which preserves the file creation date of the original file. Which it is meant to do.
Photo of Reinard Schmitz

Reinard Schmitz

  • 65 Posts
  • 8 Reply Likes
Who ever found an example on a Mac that showed a new creation date/time when copying a file? This would be horror. A copy is a copy, exactly.
Photo of John R. Ellis

John R. Ellis, Champion

  • 4698 Posts
  • 1272 Reply Likes
Let’s use the same widely-used terminology as operating-system and application developers, so that we can all communicate and have a chance of understanding each other, and more importantly, so that others in the same situation reading this thread have a chance of making sure they preserve their creation dates.

The Mac filesystem proper doesn’t preserve creation dates of copies – it’s applications like Finder and Photoshop that preserve creation dates. To see what the Mac filesystem proper does, just use the Mac command-line tools, as Alan Harper (the original poster) has done. When you use “cp” or similar commands to copy a file, the creation date and modification date are set to “now”.
Photo of Reinard Schmitz

Reinard Schmitz

  • 65 Posts
  • 8 Reply Likes
So the Finder is correcting what already the OS is doing wrong. Learned a lot today... Never copy in the terminal.
Photo of Brian M.

Brian M.

  • 21 Posts
  • 2 Reply Likes
In Re: Bob,

At least in my case, I've got images going back almost 25 years. LONG before there was any meaningful implementation of any sort of image metadata. So for those images, file creation date is the *only* way to keep track of which ones came first. They don't *have* any metadata. At the time they were created, relying on the file system was the only game in town.
Which also means that if LR corrupts that file system data, I'm screwed. Believe it or not, I do still reference some of those images, even still.

Arguing about what we *should* do, moving forward, in terms of how we organize our data doesn't help people like me with large, long-term image archives. I've already got tens of thousands of images where I have no choice but to rely on the file system date. After all, it worked just fine for 25 years, across ?5-6? major OS changes, about a dozen different boxen, and 11 versions of photoshop. Why does LR get to break the system?
(I think this all started out on Mac System 6. Been a while...)

At least for me, this is specifically a Mac issue. I'm not greatly interested in how the PC or explorer handle that information. I go back far enough that my attitude on that could be summed up by "of *course* windows screws it up. It's windows."

As I said before, I'd be perfectly happy with a little applet that you dump files on, and it takes the file system file creation date and loads it into the metadata file creation date.
I'd like to see LR fixed, but I'll settle for getting all my data correctly coded so I don't have to worry about it again.

I'll take a swing at John Ellis' method tonight, and see how that works. It may solve the problem.
Or at least provide a workaround that works well enough. (many thanks)

The Ryan M. Exiftool cheatsheat seems like it may have just what I need too. I'll take a swing at that too. One of them may work...

Regards,
Brian
Photo of Brian M.

Brian M.

  • 21 Posts
  • 2 Reply Likes
Report from later:
John Ellis' method does work. Takes some fiddling around, but it does work.

There's also a script for EXIFTool on the Ryan M. cheat sheet page that works as well.
The only hitch is that it creates both a modified and original file. So just delete the originals after you import (and test) the modified versions.
Paste this into terminal once you've CD'd to the correct directory:

exiftool '-datetimeoriginald still like to see LR fixed though.

Thanks
Brian
Photo of Brian M.

Brian M.

  • 21 Posts
  • 2 Reply Likes
whoops. The forum ate the script.

I'll try to re-post it below.

exiftool '-datetimeoriginal
Photo of Brian M.

Brian M.

  • 21 Posts
  • 2 Reply Likes
Really doesn't seem to like the script.

Follow this link:
https://ryanmo.co/2014/09/28/exiftool...
Then look for
Update any photo that doesn't have DateTimeOriginal to have it based on file modify date

That'll get you there.
-B
Photo of Robert Frost

Robert Frost

  • 435 Posts
  • 73 Reply Likes
Another alternative that I have used is to rename the files whose old create dates you want to keep, by using the LR rename to incorporate the Capture/create date and time. OK the filename is also just part of the file system, and not part of the actual file, but it is less likely to get changed by anything than the filesystem dates.

I've recently followed Victoria Bampton's (Lightroom Queen) advice and renamed all my files by putting date-time in front of each filename.

But with my old transparencies, I don't have precise capture dates (other than the camera Exif dates when I re-photographed the transparency), so I manually add the date on the transparency to the filename.
Photo of Brian M.

Brian M.

  • 21 Posts
  • 2 Reply Likes
I think the various solutions above have set me up to solve my problem, to the extent that it can be solved, but just for the sake of completeness, please follow along here, in regards to any suggestions of renaming:

We can't.

Please remember that this is an image archive going back nearly 25 years. Tens of thousands of images. Images which are referenced *BY NAME* in other files. (Quark, InDesign, etc. Thousands of them.)

The only solution that will work is to add metadata fields to the files that lack them (most) and then load the original filesystem creation date into the creation date in the new metadata. Screwing around with the names is not possible. Hand-editing the date info is not going to happen. It has to be an automatic process.

I just wish this level of fussing wasn't necessary. It's a simple thing really: don't screw up the file origination date when you touch it. Simple. Normal. Good, basic programming practice. (that most other Adobe products follow....)

-B
Photo of Reinard Schmitz

Reinard Schmitz

  • 65 Posts
  • 7 Reply Likes
Ist really simple. Don't touch the creation date... Really. And no excuses, no further explanations.
Photo of John R. Ellis

John R. Ellis, Champion

  • 4710 Posts
  • 1277 Reply Likes
To clarify so that everyone is on the same page with regards to facts, the OS X filesystem proper does not automatically preserve creation dates when files get copied or new versions get created. With regards to creation and modification dates, the filesystem is similar to that of Unixes and Windows.

Rather, by convention, many if not most Mac applications try to preserve the creation dates of files when they create new versions of the file, even when creating a new version by writing a brand new temporary file (with a new creation date) and then renaming it on top of the previous version. Some of the application libraries and frameworks that developers use provide support to make this easier (though it's not that hard in any case). But preservation of creation dates is not something that is automatically done by OS X -- the developer has to take extra steps to make it happen. Clearly, LR's developers have not taken that extra step.

This convention does not appear to be documented in Apple's developer documentation and application guidelines.

As I described above, not all Mac apps preserve creation dates for new versions of files. Of the modest set of applications on my computer, Google's Picasa and Apple's iPhotos don't preserve creation date, but all the others do, including Photoshop, Bridge, and Acrobat. I found online bug reports from a few months ago where Synology network attached drives don't properly maintain creation dates. The low-level command-line tools like "cp" also don't preserve creation dates.
Photo of Reinard Schmitz

Reinard Schmitz

  • 65 Posts
  • 8 Reply Likes
I think you are wrong. Using Finder

1. Duplicates get the same creation an modified date on the same volume
2. Copied versions on another volume keep creation and modified as well
3. Only the added date and time have the date/time added if you use the duplicate command - or no values :-(

I just double-checked it.

(OS X 10.5.5 b)
Photo of John R. Ellis

John R. Ellis, Champion

  • 4710 Posts
  • 1277 Reply Likes
Yes, the Finder preserves creation dates. But it does so because it takes explicit, application-level steps to do so, not because the underlying OS X filesystem automatically preserves creation dates.

You can observe that the filesystem itself does not automatically preserve creation dates by running a command-line tool like "cp" or "exiftool" in the Terminal window.

It's important for those wishing to preserve their creation dates to understand this distinction between applications and the filesystem. Because the dates are not automatically preserved by the filesystem, applications must take explicit steps to preserve the dates (or use libraries that do that for them). This makes it more likely that some applications, especially those like LR, Picasa, Dropbox, or "exiftool" that are ported to multiple platforms, will "forget" to follow the Mac conventions.
Photo of Brian M.

Brian M.

  • 21 Posts
  • 2 Reply Likes
Solution found: Exiftool comes to the rescue again.
Since it seems not to like me posting scripts, I'll save the script to the end.
But the short version is to CD to a target directory, then use a modified version of the script above, modified to be recursive, an then do a recursive exiftool 'delete original' to clean up the extra files.
At the end of the command, the example will be set to TIFF. If you want to go after JPGs, switch it to JPEG. I've tested it with both, and it works with both. Haven't quite had the guts to try the EPSs yet.

John: why are we arguing file system behaviors? What I can tell you is that the files have survived 25 years with uncorrupted creation dates. That's really all I care about, not the minutiae of *why*. Some of these files are so old they go back to the original Mac file system which didn't need extensions. In fact, we were pretty aggressive about deliberately not using them, just to piss off the PC users. Much fun with those now.
I think I've even got a few files that got salvaged off of my old Lisa and Apple 2. So the minutiae of the file system are of no great interest to me. What matters is keeping the collection integrity intact.

Anyway, here's the script. Enjoy. Run the first part, then run the second, that'll clean up the duplicate 'original images'. Many thanks to my buddy Jeff who helped me iron out the mods.

-B

exiftool -r '-datetimeoriginal .

exiftool -r -delete_original .
Photo of John R. Ellis

John R. Ellis, Champion

  • 4703 Posts
  • 1275 Reply Likes
But if the computer crashes, you'd have to do some careful examination to see if it crashed while writing the _tmp file (in which case the _tmp is invalid and should be discarded) or while copying the _tmp file back to the original (in which case the original should be discarded and the _tmp file renamed to the original). If you were processing a large folder of pics during the crash, you'd have to remember to look!
Photo of Brian M.

Brian M.

  • 21 Posts
  • 2 Reply Likes
Yeah, but for most people, the EXIFtool update will be a one-time thing, to get the archive up-to date with a current file format. Even with the 'update original in place' flag set, EXIFtool still updates the creation time to current, but I don't care so much: the original creation date has been loaded into the metadata (which the image now has), where it's much safer, and less likely to get banjaxed by sloppy coding. Worst case, dupe the directory via file system (not CP) and then delete the copy once you're sure everything's good.
The odds of it blowing up during a one-time file update, on a cloned directory, are trivial.

Normally, I do a DIFF when pulling things off the old CD's. That won't work here. But you get the idea: check, verify, *THEN* delete. If it does all go south during an update, don't waste time trying to figure it out, just nuke the working directory, and start over from the original.
This is mostly so I can find the JPGs and TIFFs that're scattered through the whole archive. The prepress, PS, and EPS files won't be changed, so most of the critical chronology is unaffected.

Note to the future: the exiftool command to do the update with the original in place, which saves the delete step is:

exiftool -r -overwrite_original_in_place '-datetimeoriginal<filemodifydate' -if '(not $datetimeoriginal or ($datetimeoriginal eq "0000:00:00 00:00:00")) and ($filetype eq "TIFF")' .

-Brian
Photo of John R. Ellis

John R. Ellis, Champion

  • 4703 Posts
  • 1275 Reply Likes
The Exiftool script looks like it should be very helpful for others. For anyone else reading this, can you give some details why you went with the script rather than using LR's Edit Capture Time command? (I have a bias in favor of Exiftool myself, but details would be good...)
Photo of Brian M.

Brian M.

  • 21 Posts
  • 2 Reply Likes
Two reasons:
A) don't trust LR not to foul it up again, and (B) I've got directories nested 6-8-10 layers deep.
Doing it from the command line gets them all, with no questions asked, quickly and dependably. I'm going to do segments of the archive at a time, just so if there *is* a problem, it doesn't take out the whole thing.

I also haven't quite decided how I'm going to handle the update. This is a prepress archive, so there are all sorts of files in there that LR can't touch. So I'm debating whether or not I fork the archive, and use EXIFtool to create dupe files *with* the metadata, while leaving the originals alone. Use EXIFtool to move the updated files to a new scanable archive, then let LR grab hold of those dupes. So I can search the tiffs and JPGs, and if I really need the rest of the package, I can go back and pull it from the morgue.

I'm using LR more like a DAM package than any sort of manipulation program. I like how it handles keywords & etc far better than Bridge, with the glaring exception of fouling up the file dates.

-Brian
Photo of John R. Ellis

John R. Ellis, Champion

  • 4703 Posts
  • 1275 Reply Likes
Thanks, that could help others in the future.
Photo of Brian M.

Brian M.

  • 21 Posts
  • 2 Reply Likes
Damn, it really hates that script. Think I know why.
In the following, replace "@" with the less than symbol (left pointing pointy parens.)
That should get it thru.
-B

exiftool -r '-datetimeoriginal@filemodifydate' -if '(not $datetimeoriginal or ($datetimeoriginal eq "0000:00:00 00:00:00")) and ($filetype eq "TIFF")' .

exiftool -r -delete_original .
Photo of Steve Sprengel

Steve Sprengel, Champion

  • 2675 Posts
  • 348 Reply Likes
The messages on this forum allow some HTML which oftentimes are enclosed in < and > signs.
Photo of Steve Sprengel

Steve Sprengel, Champion

  • 2675 Posts
  • 348 Reply Likes
So instead of using the less-than and greater-than signs use &lt; and &gt;
Photo of Robert Frost

Robert Frost

  • 435 Posts
  • 73 Reply Likes
There is a plugin for LR that allows you to copy capture times from LR into Exif in your images.

http://www.photographers-toolbox.com/...

Bob Frost
Photo of DavethePaintingGuy

DavethePaintingGuy

  • 2 Posts
  • 0 Reply Likes
Just discovered today that photos I have renamed using LR 5 have new Crested Dates, and the Modified Date matches.

That is a HUGE problem with my nearly 100,000 photos I trusted to Adobe.

There is no reason whatsoever to change the creation date when changing a name of a file. Period.

Now my library is hosed. I can no longer find files by the dates I knew I shot them.

It's irritating, too, to read through this set of posts and see all the pompous responses, from questionably-authoritative "this is what Adobe safely does" to the missing-the-point suggestions on how to fix, to the "missing the point" pontifications on "here's how I always do it form the beginning."

The POINT is that Adobe really screwed up with the mac Version and they still have not fixed it.

My trust of Adobe has severely diminished. Forcing "subscriptions" to software I formerly licensed at a very high cost was the first nail. This may be the last, Adobe.

Sadly, Apple is following their lead and taking Photo apps back to the stone age.

I'm so, so upset by this. I can no longer recommend Adobe products.
Photo of Brian M.

Brian M.

  • 21 Posts
  • 2 Reply Likes
Yes. Thus my annoyance earlier in the thread. Fortunately, I figured it out before I screwed up any files I couldn't get back from CD, but yeah. You are not alone.

As far as the subscription model goes: no bloody way. I'll stick with CS6 until Apple does something that breaks it for good. (And given the bad blood between Apple and Adobe, I don't think they're likely to do that anytime soon.)
All of the prepress people I know are staying with CS6 for the foreseeable future.
All in all, not a good couple of years for Adobe.
Seems they forgot *why* we all jumped ship from Quark as soon as ID got good enough: Quark had spent *years* taking us for granted, and treating us like cash cows. Sound familiar?

-Brian
Photo of Robert Frost

Robert Frost

  • 435 Posts
  • 73 Reply Likes
Another pompous reply - just go back to the backups of your 100,000 images before you renamed them. They will still have the dates you want presumably. But for goodness sake if you've been relying on the filesystem dates, get them into exif/iptc or into the filename asap. I've just done both with my 90,000 images - belt and braces. Now the images sort the same, whether they are sorted by filename or capture date. Filesystem 'create' dates are NOT reliable.

Bob Frost
Photo of Reinard Schmitz

Reinard Schmitz

  • 65 Posts
  • 8 Reply Likes
Exactly. That's exactly my point of view. I will cancel the subscription for this bug.
Photo of Robert Frost

Robert Frost

  • 435 Posts
  • 73 Reply Likes
Reinard, I think you've got it wrong. The filesystem 'create', 'modified', and 'accessed' dates were designed for the filesystem of your OS, whether Mac or Windows, to keep track of all your files, program files as well as image files. They were NOT designed to record the date on which you took your photos. The Exif 'capture', 'digitised', and 'modified' dates were designed specifically for this purpose, for us as photographers to use, and are stored in our images files, not in the filesystem.

So why try and use the filesystem dates when we have our own specifically designed dates in the actual image files?

As for blaming Adobe, Adobe is so scared of altering your image dates, that is only allows you to alter 'capture' dates in raw files, after you have given them special permission to do so, in your prefs.

So don't rely on filesystem dates that have always been flaky, and probably always will be, and that can be altered by the OS and programs without you knowing.

Bob Frost
Photo of Reinard Schmitz

Reinard Schmitz

  • 65 Posts
  • 8 Reply Likes
I am absolutely right. Completely. Adobe is not allowed to touch the creation date as I wrote for several times in these posts. It's a bug they have to correct. They don't have it in other products. Creation date is exactly a file related system item which must not be changed by anybody; the file was created at that date. Once and for ever. Period. Why we should have a OS that is looking for these dates when any buggy software changes it? First point.

Second point, I repeat this again: The EXIF dates are unusable if you need a timeline of you photos in Finder. This is absolutely necessary if you are travelling and have hundreds of pictures every day of several cameras. How you ever would be able to sort them in a time line???

That's why I copy the EXIF date from every photo to creation date from time to time to correct buggy software which changed creation date mistakenly. BTW: »A Better Finder Attributes 5« doest this job perfectly.

For me LR seemed to be a good software to manage my about 200.000 photos. But it isn't. That's why I have canceled my subscription to CC. The older PS and LR are still good enough, other SW not mentioned.
Photo of Robert Frost

Robert Frost

  • 435 Posts
  • 73 Reply Likes
Second point, I repeat this again: The EXIF dates are unusable if you need a timeline of you photos in Finder. This is absolutely necessary if you are travelling and have hundreds of pictures every day of several cameras. How you ever would be able to sort them in a time line???
.......................

I don't use Macs, but I take thousands of pictures on two or three cameras while travelling, and provided I have remembered to sync the date-time on the cameras before I go, I have no problems sorting them by capture date/time in exif. The only problem is if I am taking several images per second. Then those can get sorted by camera internal file name, if necessary.

Creation date is exactly a file related system item which must not be changed by anybody; the file was created at that date. Once and for ever. Period.
..................................................

The filesystem creation date is NOT permanent; at least not in Windows. It is a file creation date, so if you copy a file, the copy will have a new creation date - the date on which the copy was created. Quite logical. Then the file system can distinguish between the copy and the original. It doesn't usually change when you rename a file, but loads of programs and utilities can change these filesystem dates. They are not immutable. The exif dates are much more reliable, and are in the actual files, wherever you move them or copy them.

Why do you think Exif dates were created? To avoid the problems with filesystem dates and create permanent records of the capture, digitised, and modified dates for us photographers.

Bob Frost
Photo of Reinard Schmitz

Reinard Schmitz

  • 65 Posts
  • 8 Reply Likes
To use EXIF date for sorting it's necessary to use a tool. In the finder it is not applicable. So to copy the exif date to creation date is the best way for me - if there is one. So I created it in old photos first. ExifTools helps a lot. So in the end I can go without LR...
Photo of Brian M.

Brian M.

  • 21 Posts
  • 2 Reply Likes
Robert, please follow along:

A) we've been talking about Mac file systems. Windows behaviors are cute, but irrelevant here.

B) at least in my case, (don't know about the others) I'm using LR to keep track of images that either predate metadata, never had any to begin with, or were generated by Photoshop/god-knows-what, and never had any metadata from any sort of camera, because they weren't photos. Even my Nikon film scanner didn't do metadata, back in the day.
I've got drum scans of Apollo negs straight from NASA that don't have any metadata in them.

So the 'why use the file date?" question has been answered over and over again: because we have no choice. Kibbitzing about it being a bad idea doesn't help.
If I'd *known* that, 25 years ago, I might have set up a different system. But I didn't. So now I'm stuck with making the archive I do have work.

For me, this isn't about photography, it's image archive management. I can't change the file names, and I have to depend on the file origination dates being good, at least until I can use EXIFtool to load them into the (newly generated) metadata, where they're still searchable, and less likely to get screwed up by sloppy coding.

For people following along this thread later, follow back thru, and I've got a method using EXIFtool to load the creation dates into the metadata that should be of use to you.

-Brian
Photo of Mixapix

Mixapix

  • 18 Posts
  • 0 Reply Likes
A latecomer here as I just learnt about it from another forum where I raised the same problems but haven't yet quite found out why and how to solve it.

I'm using Lightroom 5.7.1. on a Mac with OSX 10.9.5. and have organized my photos in such a way that they can just as well be found in the OSX Finder and not just LR, which is why Creation dates are just as important as the EXIF dates to me. Much to my shock I found out that over 2000 of my photos had their Creation dates changed, and I've since tried to figure out why and how to prevent this from happening again (fortunately I have backups, but it's going to take forever to restore them, given all the different locations they're in).

So there's a lot of disagreement on why this is happening, and if it's a bug or feature.
I read earlier in this thread where Steve Sprengel says the purpose of all this is to have LR write a temporary file while adding the keywords, then creating a new file with those keywords. Well, that doesn't explain why Adobe in their wisdom didn't put in a couple of extra lines of code to overwrite the new file's Creation date with the original Creation date as should be (after all, the file, as seen from the user's point of view, hasn't been re-created, just had some new information added to it -so this should essentially just leave a changed Modification date).

To me all this is definitely a bug because IMHO no software should tamper with the date a file was created without alerting the user at least, no matter what. My tests indicate that many of the files can be fixed by using "A Better Finder Attributes" with the "Copy EXIF to Creation date" setting, but once I add/change the keywords for those files again in LR the date is yet again updated to now.
I could probably decide never to change the keywords ever again, run the above software to fix the date, then lock all those files in OSX' Finder, or just avoid saving the EXIF data (CMD-S) in LR (I suppose this keeps the keywords etc. within the LR catalog and not in the files themselves).

Someone told me the problem appears whenever you have a photo in LR which doesn't have all the usual EXIF time/date tags, such as a scanned image or old digital camera, but this surely isn't it because I just imported several Canon G7X shots today and the JPG files got their dates changed (I usually shoot RAW but some JPGs were generated when I set the camera to a different mode it seems).

Has this problem been fixed in LR 6? Has Adobe responded to this bug report at all or are they just pretending it's not there or a nice feature (for some unknown purpose)?
Photo of John R. Ellis

John R. Ellis, Champion

  • 4698 Posts
  • 1272 Reply Likes
If you decide to continue relying on the file date created as the "truth", beware that a significant minority of Mac apps other than LR don't preserve it, and most cloud services won't either. So before using any new app, utility, script, network drive, service, etc., carefully test it to make sure it preserves date created.

Regardless of whether Adobe eventually fixes LR to follow the convention (as Photoshop and Bridge do), I highly recommend that you transition to storing capture time in the photo industry-standard XMP and EXIF metadata. Nearly all photo apps and Web services implement those standards and is the best way of preserving your date/times for the long term.

Then, if you want to use Finder for browsing, use one of the methods described in this thread: use a utility or plugin for copying the metadata capture time back to date created, or rename your files to include the original capture date.
Photo of Alan Harper

Alan Harper

  • 458 Posts
  • 94 Reply Likes
Hi Mixapix.

Welcome to the Adobe Lightroom (female dog)-a-thon.

I think your options are
a) live with it
b) move to Windows (it appears that this is a Mac-only bug)
c) rename your photos so that they start with the date in YYYY-MM-DD HH-MM-SS format, so you can sort by name and achieve sort by exposure date.

I do the the third.

(Adobe doesn't like the 5-letter word for female dog.)
Photo of Reinard Schmitz

Reinard Schmitz

  • 65 Posts
  • 8 Reply Likes
There are some more options or workarounds:

d) Leave LR (I will)
e) give your photos exif dates if they don't have it yet and copy the exif date back to the creation date (I do this from time to time). ExifTool helps to do both.

Didn't find better solutions. (b) is the best joke ever.
Photo of John R. Ellis

John R. Ellis, Champion

  • 4698 Posts
  • 1272 Reply Likes
"b) move to Windows (it appears that this is a Mac-only bug) "

LR CC 2015.3 (Windows 10) doesn't preserve file Date Created either. In general, Windows has never had the convention of preserving it, as there has been on Mac.
Photo of Reinard Schmitz

Reinard Schmitz

  • 65 Posts
  • 8 Reply Likes
Sorry, (b) was a joke by me. I would never change back to Windows whatever will happen... :-)
Photo of Jim Wilde

Jim Wilde, Champion

  • 393 Posts
  • 154 Reply Likes
I'm not seeing this, John. I've run the same tests, many times, on both OSX and Windows10 (adding metadata to a jpeg in Lightroom, then doing Cmd/Ctrl+S), but the Date Created is only updated on the OSX system.
Photo of Robert Frost

Robert Frost

  • 435 Posts
  • 73 Reply Likes
I also do the rename with date first, as recommended by The Lightroom Queen I believe! It solves other problems as well, such as exporting without metadata but keeping a copy.

Bob frost
Photo of Brian M.

Brian M.

  • 21 Posts
  • 2 Reply Likes
John: Where do you vote on this issue? God knows I consider it an incredibly sloppy bit of coding. It sort of reminds me of the joke about M$ back in the old days: "How many M$ coders does it take to change a lightbulb?" "None. They just redefine darkness as the new industry standard". Calling it 'standard' doesn't mean it's not busted.
Photo of John R. Ellis

John R. Ellis, Champion

  • 4592 Posts
  • 1237 Reply Likes
It's conceptually a very simple change to make (on both Mac and Windows), and I certainly wouldn't object to the change. But it's not important to me, since I decided a long time ago not to rely on file creation dates -- there are too many programs, utilities, and services on Mac that don't maintain it, and if I accidentally run one of them, I've silently lost all my dates.

Your best shot at getting Adobe to pay attention is to get more people to vote for this topic (and support their vote with substantive details on why it matters to them).
Photo of Mixapix

Mixapix

  • 18 Posts
  • 0 Reply Likes
Brian M: I assumed this forum (like most other forums) would allow for attachements, but I see no such feature unfortunately.
Perhaps one of the many file-upload services would do, then post the download URL here? I think there are still a few left that don't need registering etc. but alas I haven't used any of them.
Photo of Mixapix

Mixapix

  • 18 Posts
  • 0 Reply Likes
John R. Ellis: about the scanning options; no, unfortunately I don't have any such advanced options with my Brother multifunction printer. I can choose to have the filename dated and/or a common name for all scans preceeding the file number, but that's about it.
Maybe I should create a "drag & drop" dock-droplet for copying the OSX Creation date over to the EXIF "DateTimeDigitized" tag then, for anything I scan, and of course have the scanner software name the file itself with the date. I suppose this would be possible with EXIFtool?

About voting for Adobe to fix this nasty bug: it appears most LR users simply don't care about the altering of the OSX Creation date, probably because they just don't handle their images with anything but LR, or don't yet understand the significance of it in case they need to handle them outside of LR some day, and Adobe it seems (not surprisingly) is all about the $$$ and not going that extra mile to keep the customer happy. So in the end it looks like we have to find workaround like the ones discussed here instead.

Once I've figured out all of this I hope to be able to set up some sort of "fix LR-messed up images" script, droplet or something similar which will perform all the tasks needed in one go. I'm sure that a year from now I won't remember all the details about creating a new EXIF date header for newly scanned files (before importing them into LR) and a different situation for those files as well as JPGs where the EXIF date info should be copied over to the OSX Creation date, and yet another procedure for renaming all files by adding the EXIF date to the file name.
In the end we should be spending more of our time taking photos than mess around with these sort of organizing issues in LR which was created in order to help us do just that :-(
Photo of John R. Ellis

John R. Ellis, Champion

  • 4592 Posts
  • 1237 Reply Likes
"Maybe I should create a "drag & drop" dock-droplet for copying the OSX Creation date over to the EXIF "DateTimeDigitized" tag then, for anything I scan, and of course have the scanner software name the file itself with the date. I suppose this would be possible with EXIFtool?"

It's certainly possible to use a command-line script. Someone else here thinks they can create a drag-and-drop icon that will invoke Exiftool -- that sounds plausible to me but I don't know how to do it.
Photo of John R. Ellis

John R. Ellis, Champion

  • 4710 Posts
  • 1277 Reply Likes
Jim Wilde wrote, "I'm not seeing this, John. I've run the same tests, many times, on both OSX and Windows10 (adding metadata to a jpeg in Lightroom, then doing Cmd/Ctrl+S), but the Date Created is only updated on the OSX system."

When LR saves metadata to a non-raw on Windows, it will try to modify the file in place, overwriting the metadata fields and preserving Date Created. But if it isn't able to modify the metadata in place, it will write a brand new file and then rename that file to the original filename, thus setting Date Created to "now". Years ago, Rob Cole and I discovered this on Windows, but we didn't test Mac. (I can't find the original topic describing our tests.)

One way I've found to cause LR to write a new file is to set the caption to be very large (e.g. 250 characters) and do Save Metadata To File. Here are before and after screenshots from File Explorer showing the results (LR CC 2015.3 / Windows 10):


Photo of Jim Wilde

Jim Wilde, Champion

  • 394 Posts
  • 156 Reply Likes
Thanks. I remember the topic, though wasn't 100% certain about my memory! In effect, then, there are really two similar but not quite identical platform-specific issues?

Under OSX, the Date Created is updated to "now" when adding/changing any metadata and writing back to the file.

Under Windows, the Date Created is only updated to "now" in certain situations (when unable to update the metadata in place), e.g. adding a very large caption.

I'd been running the same tests on both platforms (added keywords, Titles, Captions, Ratings, etc.) and seeing different results, because I wasn't triggering the "unable to update in place" problem on Windows.
Photo of John R. Ellis

John R. Ellis, Champion

  • 4710 Posts
  • 1277 Reply Likes
I don't know why LR Windows and Mac behave differently on this score -- architecturally, the two OSes are very similar with respect to app use of the file system.
Photo of DavethePaintingGuy

DavethePaintingGuy

  • 2 Posts
  • 0 Reply Likes
It kinda doesn't matter if PC users can't duplicate it. Be thankful.

When you have 80,000+ pictures going back 15 years of friends, families and events and you suddenly cannot find any of them by the year you KNOW the dates from, all you can do is shrug (and be pissed).

I was trying to be more orderly and name files by familiar English words, and all the dates got changed to the day I renamed them.

All 80,000? No. But enough of the ones I cared about to rename them.

It's terribly sad how this tool that was making my life better actually complicated it in the 2nd worst way — next to losing the images.
Photo of Mixapix

Mixapix

  • 18 Posts
  • 0 Reply Likes
I couldn't agree any more. My situation isn't half as bad as yours but still very frustrating. Whatever reason, LR's way of changing Creation dates adds no benefit to anyone, just grief and frustration to those who do care about file Creation dates.

I guess besides laziness and not being willing to admit this is a mistage/bug, Adobe just probably assumes that when you use LR that's the only system you'll ever use to organize your photos.

Do you have a backup of your files with the correct dates?