'Date Created' changes to 'Date Modified'

When I modify pics using Picasa and then export them to a new folder, 'Date Created' changes to be the same as 'Date Modified'. Is this a bug? When I look at the exported pic info in Picasa, the Date Created is still correct, but when I view the same pic in Finder, the Date Created is now the same as Date Modified. But when I look at the original pic before Picasa copied it into the new directory, it has the correct Date Created. Is it possible that Picasa somehow screwed up the file info when it exported?

Update to this. I found this info in forum:
"A digital image file has two 'creation' dates, the date the image was captured by the digital device (cameras, scanner, etc) and the date the image file was created on the HD."
The problem seems to be that when I don't modify an image in Picasa, the date captured remains the date created as far as finder is concerned. However, when the image is modified (eg shadow increased), 'date captured' becomes 'date created to HD'.
So apart from this being nuts, how can I get Finder, and therefore AppleTV, to sort and play by original image capture date created?
This might also be an AppleTV question.

Similar Messages

How do I change or remove default apps for a given file extension (in Terminal?) without munging date modified on all my old files?

When a program is installed, it seems to be able to do it (sometimes inappropriately if it hijacks file associations without asking) so why can't I? This is for 10.4.
Specifically:
1. Since installing an HP wireless printer, HP not only tries to install a bunch of sales-ware on your machine that you have to carefully opt out of (annoying, but not a problem if forewarned), it changes the default file association for a number of basic file types, listing all sort of existing files as HP printer files. Using Get Info to change the default file type association globally causes it to mark ALL the files of that type as newly updated, munging the file metdata (which HP did NOT do). Most of the stuff on our computer is sorted by last modified, so if there is a way to fix this in Terminal (to simply fix or remove the HP default tag) without changing the date the file was modified, it would help. Note that uninstalling the program that created the default would do this, but I obviously can't do that (and reinstalling HP would have the same effect). So there has to be another way, right?
2. Since updating iTunes to v.9 a while back, every mp3 is marked as an iTunes file even though iTunes has NO multiple library capability without a wonky reboot using the option key, meaning that if I click on an mp3 downloaded since last update of iTunes, it opens automatically in iTunes and gets added to the SOLE itunes library without asking. (There is no way to toggle between multiple libraries or archive media in separate folders; iPhoto has a similar problem. (Has this been fixed in the latest version of iTunes?) In comparison, Quicktime starts up immediately and does not attempt to create a playlist just because you opened a file and listened to it.
(The iTunes playlists are simply subfolders of the single main library -- and you can't create a new library without doing a wonky procedure by clicking option during startup and telling iTunes to forget where its library is located (includin everything in it) and look up an entirely separate one by hand. So any mp3 file downloaded recently is uploaded to iTunes if you click on it. This wouldn't be problem if it didn't automatically add it to the sole iTunes library just because you clicked on it.)
Besides, all my old mp3s are Quicktime files and they are all archived by date modified. To its credit, ITunes, unlike HP, does NOT hijack older files already on disk and remark them as iTunes files. It only marks newly downloaded files as such. But if I try and change file association for FUTURE mp3 files using Get Info > "use this program for all files of this type", it munges the file metadata (date modified) for all existing files!
Note that in HP case, it apparently does it at the file exchange preference level (or whatever it's called) since the OS then recognizes every file of those types as an HP file. In the iTunes case, it only does it if you download a new media file or open an existing file in iTunes, but again without changing the date it was last edited.
Since these programs are able to change the default file association without changing the date the file was last edited, it should be reversible in Terminal, correct? Why does it change "date modified" when you try and correct metadata using Get Info (or sometimes just by clicking an enclosing folder?) Date modified should be a record of when a file itself was edited, not when it was renamed, or other metadata. Otherwise stuff can't be sorted correctly.

The unix commands you need are:
GetFileInfo
SetFileInfo
and maybe find
for cryptic details use the man command
Macintosh-HD -> Applications -> Utilities -> Terminal
man SetFileInfo
You may use the SetFileInfo command to set the file type & the program which will open the file.
# This little gem will do a get info on all files in a directory.
mac $ ls | xargs -I {} GetFileInfo "{}"
file: "/Users/mac/playdoc/oddadocodd"
type: ""
creator: ""
attributes: avbstclinmedz
created: 05/01/2011 14:53:22
modified: 05/01/2011 14:53:22
file: "/Users/mac/playdoc/one.docx"
type: ""
creator: ""
attributes: avbstclinmedz
created: 05/01/2011 13:57:48
modified: 05/01/2011 13:57:48
file: "/Users/mac/playdoc/oneLineFile"
type: "TEXT"
creator: "!Rch"
attributes: avbstclinmedz
created: 05/07/2011 14:27:17
modified: 05/07/2011 14:27:17
file: "/Users/mac/playdoc/oneLineFile.txt"
type: "TEXT"
creator: "!Rch"
attributes: avbstclinmedz
created: 05/07/2011 14:27:49
modified: 05/07/2011 14:27:49
file: "/Users/mac/playdoc/three.docx"
type: ""
creator: ""
attributes: avbstclinmedz
created: 05/01/2011 13:58:03
modified: 05/01/2011 13:58:03
file: "/Users/mac/playdoc/two.docx"
type: ""
creator: ""
attributes: avbstclinmedz
created: 05/01/2011 13:57:56
modified: 05/01/2011 13:57:56
file: "/Users/mac/playdoc/weirder.doc.docx"
type: ""
creator: ""
attributes: avbstclinmedz
created: 05/01/2011 14:50:03
modified: 05/01/2011 14:50:03
# well, ! is a funnie character so we escape it.
mac $ SetFile -t TEXT -c \!Rch two.docx
mac $ GetFileInfo two.docx
file: "/Users/mac/playdoc/two.docx"
type: "TEXT"
creator: "!Rch"
attributes: avbstclinmedz
created: 05/01/2011 13:57:56
modified: 05/01/2011 13:57:56
mac $
mac $ date
Sat May 7 14:40:56 EDT 2011
mac $

Is there a way to manually custom-edit the "Date created" and "Date modified" attributes of files in Mac OS 10.6?

In "List View" in a Finder window, among the many column options are "Date created" and "Date modified." In "View Options" (command-J) for any folder, one can add these columns, along with the standard ones "Size," "Kind," "Label," etc.
A user can alter a file's name, and a file's "label" (i.e. its color). On the other hand, a user can NOT arbitrarily edit/alter a file's official "size" -- other than by physically altering the contents of the file itself, obviously.
But what about a file's "Date created" and "Date modified"? Can either of those be manually edited/changed, just as a file's name can be changed -- or is a file's creation-date an immutable attribute beyond the editorial reach of the user, just as a file's "size" is?
And yes, a person can "alter" a file's "Date modified" by simply modifying the file, which would change its "Date modified" to be the moment it was last altered (i.e. right now). But (and here's the key question) can a user somehow get inside a file's defining attributes and arbitrarily change a file's modification date to be at any desired point in the past that's AFTER its creation date and BEFORE the present moment? Or will so doing cause the operating system to blow a gasket?
If it is possible to arbitrarily manually alter a file's creation date or modification date, how would it be done (in 10.6)? And if it is NOT possible, then why not?

sanjempet --
Whew, that's a relief!
But as for your workaround solution: All it will achieve is altering the created and modified dates to RIGHT NOW. What I'm looking to do is to alter the modification/creation dates to some point in the past.
I'm not doing this for any nefarious reason. I just like to organize my work files chronologically according to when each project was initiated, but sometimes I forget to gather the disparate documents all into one folder right at the beginning, and as a result, sometimes after I finish a job, I will create a new folder to permanently house all the files in an old project, and when that folder is places in a bigger "completed projects" folder and then is organized by "Date created" or "Date modified" in list view, it is out-of-order chronologically because the creation and modification dates of that particular project folder reflect when the folder was created (i.e. today), and not when the files inside the folder were created (i.e. weeks or months ago).
The simplest solution would simply to be able to back-date the folder's creation or modification date to match the date that the project actually started!

Detection Method of Date Modified fails due to copied files date modified change

I've been working through an issue for some time now and I think it's a bug with SCCM 2012 SP1. I've built literally 50 deployments in "Application Management" in SCCM 2012, but I've been chasing my tail on a few of them throwing the
"succeeded but couldn't detect" error. The few that have given me problems are all copying text files and then detect the modified date to verify that the file is there. All worked when I initially built them in Windows 8 but are now failing
randomly...even on a machine where they previously worked and I deleted the files to test the deployment again.
What I'm doing:
My java deployment requires policies which we control with the Deployment.config, deployment.properties and java.policy files. A simple script creates the directories and copies the files. I then create a deployment type for this "ConfigFileCopy.cmd"
and create a detection rule for each file that I am moving over. The detection rule looks for a "date modified" date between the beginning and end of the date for the day I modified the file. This allows me to modify the files to change our
java policies and then redeploy them with the "new" modified date as the detection rule, which forces the update.
The problem:
When I first created my deployment, everything worked pretty well. The files copy out and the script runs successfully. There were some minor tweaks I need to make to my scripts, so I did and then updated the content for the deployment type. I believe this
is where things go a little wonky. At this point, my deployment starts failing with the "0x87D00324" error.
Looking through the logs, everything looks good. The reason configuration manager is failing on detecting the modified date for those files, as it turns out, is because the modified dates don't meet the criteria. So that part is properly failing the detection.
The problem is that the modified dates are correct on the server but not the client. Looking in c:\windows\ccmcache, I can see multiple folders....presumably one for each version of the application that I updated. Looking at any of the newer content folders
for this app, the modified dates are the date and time the file was copied out to the workstation, which is incorrect as the file hasn't been modified during that process.
The odd part, is that this doesn't happen EVERY time on EVERY machine. My primary desktop is windows 8.1 and received the files correctly and installed without issue. My test win 8.1 laptop initially received them correctly, but then as I refined the scripts
it began picking up the wrong modified dates and started failing.
I found a similar issue to this existed in SCCM 2007 (http://support.microsoft.com/kb/2276865) so I suspect that this is truly just a bug that hasn't been addressed (or maybe is fixed in R2). Unfortunately
we have business reasons we can't upgrade to R2 at this time so I'm hoping someone has experienced this and has some sort of work around that might get me by for now. If someone can confirm it is fixed in R2, that would help my case to upgrade as well.
I can work around the issue by changing my logic to detect any date greater than a specific date. But I shouldn't have to do that and I'm concerned there are scenarios I haven't thought of that will cause unexpected behavior or failures with that.

This outlines the behavior. It's apparently by design.
"SCCM has a habit of changing the ‘Date Modified’ timestamp of all files it delivers when it detects an ‘upgrade’ of the source files for that application. It typically does not touch the timestamp
of the source files if it delivers a brand new install to a client that has never received the software, however if a single file in the source folder is changed for that application, then SCCM tries to use a previous version of the application in the cache
(C:\windows\ccmcache) and only downloads the new file that has change. This results in all files having their ‘Data Modified’ timestamp changing (except for the brand new file). Therefore determining if that application has delivered
successfully using ‘Date Modified’ timestamps is not recommended. The key to seeing this process in action is looking at the file properties in the
C:\windows\ccmcache\<sccm code> folder for that application, particularly before and after a file is updated in the original source SCCM application folder."
http://blog.kloud.com.au/tag/sccm/

PDF or Excel file saved to Network folder Intermittently has "Date Modified" changed to an older date

Client saves files locally to her Win 7 64-bit laptop and they are fine when it comes to the date modifed stamp. On occasion a few of these files each day, when saved to the home directory on the server, get the Date Modified stamp changed. Time is never
the same and can be set for las tweek or - literally - 1990, 2004, 2010, etc. I have seen tech articles talking about the different options for saving the file date based on an embedded image or attachment of some type, but that has been ruled out. And this
is not the local saved file time being modified within the first minute or two of a locally copied file.
Any ideas how a file saved to a network share can randomly and intermittently have the date modified to a much older date? Have scanned for malware as well.... Thanks!

Hi
Make sure the server or nas where it's saved is sync'ed with it,s time source, and be sure it's update for the OS's patch.
Regards, Philippe
Don't forget to mark as answer or vote as helpful to help identify good information. ( linkedin endorsement never hurt too :o) )
Answer an interesting question ? Create a
wiki article about it!

"Date Modified" changes in iTunes 11

Hi. I'm running iTunes 11 on a Windows 7 machine. I've noticed that after I close iTunes and reopen it, some of my music files get their "Date Modified" changed as soon as I play the track. This wouldn't be a problem if it happens once, but for some tracks (especially tracks I've purchased) it happens several times. One track changed three times in three days--so it's like whatever settings I created on the track don't hold (sometimes I modify the title, the artist's name or the year--and they end up reverting back to the way they were before, then I play the track and the settings change to the way I modified it). It's almost like something else is modifying the files without my knowledge.
Weird, I know. Can anyone advise how I can keep the settings? Thanks!
Doug

turingtest2 wrote:
...but I worry about the implications when people are discussing troublemakers in the Lounge or Using ASC.
I wouldn't know, despite contributing to this forum for six years, and since five points have mysteriously disappeared from my profile this morning, I'm actually getting further away from being classed as a valued contributor. (That tells me something a lot!) Actually, I think that if such a link was added to a thread, anyone clicking on it would presumably see "you are not authorised to see this post" message. Funnily enough, I see it all the time in "branched to a new discussion" links.
Clearing the browser cache appears to have solved my "add images" issue. Thanks for that. Have you noticed that the facility to edit a post (for up to fifteen minutes after posting) has disappeared? Still, at least spell check is back.
Phil

Change date modified to date taken?

I have always thought that it was crazy that the EXIF data for my digital pictures can get changed in Windows/Adobe from date taken to date modified. I have mentioned it in these forums before but never got a satisfactory answer.
I looked at the problem again & find that other have the same problem & that there appears to be a solution. I find on the net a small utility called. 'JPGDateChanger'. Before I tried it I thought that I should ask has anyone used this program & did it work correctly for them? If the change that would appear in Windows explorer have the same result in PSE 11,or does it create problems with the catalog?
If at all possible I would prefer to get this done within PSE 11. Is there any way to achieve it & if not why not?

The organizer that ships with the PRE Elements + PS elements 12 Combo pack uses the file systems Date Modified for organizing (win 8.1 64bit) . It does not use the Date Taken from the EXIF data.
This can be easily confirmed using Windows explorer. If you sort in Explorer by modified date, that is exactly the order the files appear in Organizer. If you add the Date Taken (by right clicking the column headers and adding the column) you can see the EXIF date taken field. The organizer ignores this filed in favor of Date Modified.
The workaround is to use the little JPGchanger application referenced here to set the date modified to the date taken field. This tool was specifically written to fix this issue.
The other proposed work around's involved renaming files to include date taken in the file name itself during import. Not only is that clumsy, but I have already have 10,000+ pics on my computer that aren't named that way.
My two Cameras are a Canon S90 and an ESO 550D. I also have pictures from Google Nexus5 and Samsung Galaxy phones to deal with. Not having the EXIF Date Taken field used is a MAJOR pain!

"Date Modified" for all files being changed if "Automatically write to XMP" is on

Recently upgraded from LR3 (v3.4.1) from LR2 on OSX 10.6.8 and have always had Catalog Settings > Automatically write changes into XMP turned on.
When browsing existing JPG files in my Library (no Develop changes, no keywording, no Presets, no Import), LR3 is writing to disk — i.e., when I look at files in Finder, almost every viewed file’s “Date Modified” is being set to today’s date and time. (It actually creates a .swp file, then changes it's name back to .jpg)
This is really bad, as it's making it impossible for me to use Finder to figure out when I last worked with a file, it is triggering needless Time Machine and Backblaze backups, and unnecessarily churning my disk.
If I turn off "Automatically write..." this behavior stops. Per David Marx at thelightroomlab.com, I tried turning off this preference, manually doing a "Save Metadata to File" for all files, letting that complete, then turning the preference back on. This does not solve the problem.
Per a suggestion at photoshop.com, I used ExifTool to see what changes LR was writing to a sample file; from the diff below, you can see that LR is adding a bunch of new fields as well as moving other fields around. But my point is that LR3 should never overwrite a file on disk if all I am doing is browsing thru them.
Is anyone else seeing this? Any ideas would be greatly appreciated!
-- David
diff Exif5609_original Exif5609_update
2c2
< FileName: DSC_5609_original.JPG
> FileName: DSC_5609_update.JPG
5,6c5,6
< FileModifyDate: 2009:11:27 21:32:54-08:00
< FilePermissions: rwxr-xr-x
> FileModifyDate: 2011:08:07 22:06:47-07:00
> FilePermissions: rw-r--r--
27a28,29
> ShutterSpeedValue: 1/200
> ApertureValue: 7.1
55d56
< SerialNumber: 3209521
75d75
< Lens: 18-200mm f/3.5-5.6
185,188d184
< UserComment:
< SubSecTime: 00
< SubSecTimeOriginal: 00
< SubSecTimeDigitized: 00
211a208,299
> XMPToolkit: Adobe XMP Core 5.2-c004 1.136881, 2010/06/10-18:11:35
> CreatorTool: Ver.1.00
> MetadataDate: 2011:08:07 22:06:47-07:00
> SerialNumber: 3209521
> LensInfo: 18-200mm f/3.5-5.6
> Lens: 18.0-200.0 mm f/3.5-5.6
> ImageNumber: 26634
> RawFileName: DSC_5609.JPG
> SavedSettingsName: Import
> SavedSettingsType: Snapshot
> SavedSettingsParametersVersion: 6.4.1
> SavedSettingsParametersProcessVersion: 5.0
> SavedSettingsParametersWhiteBalance: As Shot
> SavedSettingsParametersIncrementalTemperature: 0
> SavedSettingsParametersIncrementalTint: 0
> SavedSettingsParametersExposure: 0.00
> SavedSettingsParametersShadows: 0
> SavedSettingsParametersBrightness: 0
> SavedSettingsParametersContrast: 0
> SavedSettingsParametersSaturation: 0
> SavedSettingsParametersSharpness: 0
> SavedSettingsParametersLuminanceSmoothing: 0
> SavedSettingsParametersColorNoiseReduction: 0
> SavedSettingsParametersChromaticAberrationR: 0
> SavedSettingsParametersChromaticAberrationB: 0
> SavedSettingsParametersVignetteAmount: 0
> SavedSettingsParametersShadowTint: 0
> SavedSettingsParametersRedHue: 0
> SavedSettingsParametersRedSaturation: 0
> SavedSettingsParametersGreenHue: 0
> SavedSettingsParametersGreenSaturation: 0
> SavedSettingsParametersBlueHue: 0
> SavedSettingsParametersBlueSaturation: 0
> SavedSettingsParametersFillLight: 0
> SavedSettingsParametersVibrance: 0
> SavedSettingsParametersHighlightRecovery: 0
> SavedSettingsParametersClarity: 0
> SavedSettingsParametersDefringe: 0
> SavedSettingsParametersHueAdjustmentRed: 0
> SavedSettingsParametersHueAdjustmentOrange: 0
> SavedSettingsParametersHueAdjustmentYellow: 0
> SavedSettingsParametersHueAdjustmentGreen: 0
> SavedSettingsParametersHueAdjustmentAqua: 0
> SavedSettingsParametersHueAdjustmentBlue: 0
> SavedSettingsParametersHueAdjustmentPurple: 0
> SavedSettingsParametersHueAdjustmentMagenta: 0
> SavedSettingsParametersSaturationAdjustmentRed: 0
> SavedSettingsParametersSaturationAdjustmentOrange: 0
> SavedSettingsParametersSaturationAdjustmentYellow: 0
> SavedSettingsParametersSaturationAdjustmentGreen: 0
> SavedSettingsParametersSaturationAdjustmentAqua: 0
> SavedSettingsParametersSaturationAdjustmentBlue: 0
> SavedSettingsParametersSaturationAdjustmentPurple: 0
> SavedSettingsParametersSaturationAdjustmentMagenta: 0
> SavedSettingsParametersLuminanceAdjustmentRed: 0
> SavedSettingsParametersLuminanceAdjustmentOrange: 0
> SavedSettingsParametersLuminanceAdjustmentYellow: 0
> SavedSettingsParametersLuminanceAdjustmentGreen: 0
> SavedSettingsParametersLuminanceAdjustmentAqua: 0
> SavedSettingsParametersLuminanceAdjustmentBlue: 0
> SavedSettingsParametersLuminanceAdjustmentPurple: 0
> SavedSettingsParametersLuminanceAdjustmentMagenta: 0
> SavedSettingsParametersSplitToningShadowHue: 0
> SavedSettingsParametersSplitToningShadowSaturation: 0
> SavedSettingsParametersSplitToningHighlightHue: 0
> SavedSettingsParametersSplitToningHighlightSaturation: 0
> SavedSettingsParametersSplitToningBalance: 0
> SavedSettingsParametersParametricShadows: 0
> SavedSettingsParametersParametricDarks: 0
> SavedSettingsParametersParametricLights: 0
> SavedSettingsParametersParametricHighlights: 0
> SavedSettingsParametersParametricShadowSplit: 25
> SavedSettingsParametersParametricMidtoneSplit: 50
> SavedSettingsParametersParametricHighlightSplit: 75
> SavedSettingsParametersSharpenRadius: +1.0
> SavedSettingsParametersSharpenDetail: 25
> SavedSettingsParametersSharpenEdgeMasking: 0
> SavedSettingsParametersPostCropVignetteAmount: 0
> SavedSettingsParametersGrainAmount: 0
> SavedSettingsParametersLensProfileEnable: 0
> SavedSettingsParametersLensManualDistortionAmount: 0
> SavedSettingsParametersPerspectiveVertical: 0
> SavedSettingsParametersPerspectiveHorizontal: 0
> SavedSettingsParametersPerspectiveRotate: 0.0
> SavedSettingsParametersPerspectiveScale: 100
> SavedSettingsParametersConvertToGrayscale: False
> SavedSettingsParametersToneCurveName: Linear
> SavedSettingsParametersCameraProfile: Embedded
> SavedSettingsParametersCameraProfileDigest: D6AF5AEA62557FCE88BC099788BBD3CC
> SavedSettingsParametersLensProfileSetup: LensDefaults
> SavedSettingsParametersToneCurve: 0, 0, 255, 255
> IPTCDigest: d41d8cd98f00b204e9800998ecf8427e
228,230d315
< SubSecCreateDate: 2009:11:27 21:32:54.00
< SubSecDateTimeOriginal: 2009:11:27 21:32:54.00
< SubSecModifyDate: 2009:11:27 21:32:54.00
http://feedback.photoshop.com/photoshop_family/topics/lr3_date_modified_for_all_files_bein g_updated_when_browsing_photos_if_catalog_settings_automatically_write_changes_into_xmp_is /replies/6313647

clvrmnky wrote:
davidpope007 wrote:
Then when LR3 loaded my old LR2 images into memory, it "dirtied" the in-memory copy of the file by adding in these new LR3 XMP fields. Then, because I had "Automatically write XMP" on, it said "I better write these changes to disk".
Yuck. As a former software engineer, this is very bad software engineering.
It should wait until the user dirties the file (via Develop, keywords, etc.) before presuming to add a bunch of metadata fields that are unique to the new version of LR3.
Well, I'm a current software developer, and this is, really, a perfectly reasonable thing to do. It is a reasonable trade-off for a convenient feature required by a small subset of users.
Yes, in most cases the in-memory copy should "never" be dirtied unless the user makes a gesture of some sort, but like I said earlier, this option (once set by the user) sets up the situation where this gesture becomes implicit. This is a clear trade-off for the sake of convenience. And if the XMP is out of date and needs to be updated en masse, so be it.
The fact is, there is no easy way around this. Do we save up /every/ dirty buffer somehow until you make a gesture that /might/ require the XMP to be up-to-date before acting on that gesture? Now we have to worry about unflushed buffers if something goes wrong and the app exits. Do we save the buffers to the DB? Now we have to block some calls to make another blocking call to flush some or all of those to DB, and then write some or all of it out to one or more files. In what order? What if there is a gesture to have X files with up-to-date XMP and some or all of those are in unflushed buffers, unflushed DB writes or we have to wait for the DB.
As you can see, this is a transactionality nightmare, and the easiest and safest thing to get what the user wants (i.e., up-to-date XMP for the purpose of talking to a third-party XMP aware app) is to simply update the sidecar or XMP block in an atomic manner using the correct file IO. The file will have to change at some point, so it may as well be now.
[Thanks to both of you for your detailed replies. I am aware of the need for tradeoffs so when you say the approach taken is quite reasonable, I do believe you. I also apologize in advance for the length of the following and am extremely aware of the time it must have taken you to compose the above replies, but I'm going to add a bit more, if only for my own piece of mind and in hopes of coming up with a solution for my workflow.]
From my naive point of view, I was expecting the answer to be simply "don't raise the XMPDirtyFlag upon reading in a file". Obviously if your architecture requires you to "upgrade to latest XMP format" upon read, and another part of the system auto-detects "out of date XMP", then it's going to write those changes to disk.
But it didn't need to be designed that way. LR obviously has mechanisms to know when a user has made a change to XMP so it is able to write XMP changes to disk only when necessary.
The promise (to me) of "Automatically Write XMP changes to disk" was to auto-save my changes, and not those made for any internal (i.e., XMP versioning related) changes.
Perhaps the premise is that it is LR3's job to update an individual file's XMP to the latest version so that other XMP-aware apps can make use of it? I would argue that those third-party XMP-aware apps already have to know how to deal with all prior versions of XMP, so LR3 should just leave well enough alone.
You asked if my problem with your approach was that it was "inelegant"; not at all, it is based on my own perception of what I need from my workflow, so let me describe that so maybe we can find a better way:
* Part of the appeal of LR to me is that it preserves my original file as it came off the memory card, allowing me to move to a different workflow/toolset in 2025 if I choose to do so
* However, with all of changes contained in a single database file, I'm concerned about rare (but possible) corruption, so to mitigate this risk, I let LR backup my database weekly and it's also backed up continuously in the cloud via Backblaze
* Even with backups of the database, there is still a chance that I could lose changes made to individual files (e.g., LR corrupts the DB and I have to go back to last week's DB)
* Thus the appeal of the "auto-write to XMP" flag -- that way critical changes (develop, crop, keywords) are saved on a per-file basis; I liked the "automatic" part of this (as opposed to a manual save) because then I don't have to teach others in my family how to manually save XMP changes
* A nice side-effect of this setting is now when I use Finder to find a file and double-click on it to edit it in Photoshop, all my develop changes are right there; (in other words, I like the flexibility of not having to fire up LR in order to just invoke PS from within it); also when I use Bridge I see all the keywords there
* So with LR2, I had gotten used to what I thought was the best of all worlds -- autosave of changes at the file level via XMP + raw negatives untouched (i.e., Date Modified == the date I took the picture); this allows me to use operating-system-level tools -- Finder -- to locate/search for files
* Now I upgrade to LR3 and I'm finally now understanding that a concept "XMP versioning" is going to result in changes to many, but not all my files. (That's something else that's annoying about this issue -- I open up the Grid and browse a folder of files, and only seemingly random ones I've cursored over seem to get written to disk -- if it's so urgent that LR3 update the XMP, then it should do it for all the files in the catalog or at least in that directory)
Here's a screenshot from Finder of what I see everytime I look at this folder:
* So now I have to assume that each new version of XMP and/or LR is going to touch my files on disk. Sigh.
* What I don't like about this is that it is ruining the promise of "untouched raw negative". Yes, the image data is untouched -- which I agree is most of the benefit; but the file has been touched.
* Perhaps you might empathize a bit more if you imagined that someone went thru all your source code or Word files and randomly changed the date to "today" because you upgraded compilers or moved to Word 2011.
I agree all of this would be solved by having an XMP sidecar file for JPGs, but you indicate that's not going to happen.
You've also alluded to the solution of "resetting the Date Modifed" to it's original value -- which I believe is what Finder does when you move or copy a file -- but that that is fraught with issues as well. I believe you when you say there are issues, but again the naive part of me wonders why that soultion would be so bad...
I just thought of another potential solution -- turning on Date Created in Finder -- but it turns out that's changed, too.
I am really at a loss as to what to do and would welcome your suggestions.
Thanks again and kind regards,
-- David

"Date Created" or "Date Modified" field for Contacts?

Is there any way to view -- or sort by -- a "Date Created" or "Date Modified" field in Contacts?
Or, at the very least, view a single records Date Created/Modified?
In particular, when exporting the BB's Contacts to an ASCII, I'd love that field to appear.
Thanks,
MooShoo

When I open a search window (command "F") and then press Command "J" or go to "Show View Options" under the "View Menu" it just brings up a window that says: "There are no view options for the "Searching This Mac" window"
I am using OS 10.5.8 on a 1st Generation MacBook Pro. I have successfully changed view options in other folder windows, but can't in the search window. I have just started trying an Application called "Find Any File" (http://apps.tempel.org/FindAnyFile/) and it looks like it may provide what I want but is MUCH SLOWER than spotlight.

Date Created, Date Modified format

Hello.
I have set several database fields as Autogenerated with Date Created or Date Modified option in Designer 9i. TAPI generated populate the field with time value missing - only the date (e.g. '06.06.2002'). I want the field to contain time as well (e.g. '06.06.2002 11:23:34'). What Designer option to find? Thanks.
Ivan Virag

This is a preference setting, and the default is to use date only - no time value. To change the preference in the Design Editor, do this.
Select Options from the menu at the top of the screen.
Select Generator Options from the dropdown menu.
Select General... from the next level menu.
On the General Generator Options there is a checkbox labeled: Record Time On Change History Columns.
Check this box, press the OK button, and re-generate the TAPI. You'll see the TRUNC(SYSDATE) in the generated code for maintaining your Date Created and Date Modified columns has changed to just SYSDATE.
Unfortunately, this changes it for any application you generate - that is fine with me, but your requirements may vary.

How to keep Date created and Date modified when converting nef to dng

Hi
I noticed that when we convert NEF files to DNG in it properties the Date Created and Date Modifed are changed to the present date and not the original dates of the files in question. Is there any way to make such a conversion without changing these proeprties? Yes, I know 'Date taken' does not change--but this info does not show up when you hover a file only the info in its properties does hence me asking the question.
Also am I correct in assuming that this conversion is 100% lossless, nothing but nothing is lost in the qualtiy and info of the file (besides the file size)? Thank you
OS: Windows 7 (64)

A DNG from an NEF is a new file so it’s Windows dates are as of its creation on Windows. The date modified would further change if you updated the DNG with a new preview and/or embedded metadata into it.
If you need the files to have the camera’s creation date, then use Windows Explorer to copy them, don’t convert to DNG, and just Add them to your LR catalog, and tell LR not to add a timezone or otherwise adjust the timestamps which might also update the file modification time.

Why does placing links in Illustrator now change the "Date Modified" data for all of my files?

This seems to be a new glitch that started after I installed the latest updates to Illustrator CC (2014) and reoccurs every time on both computers I work on:
When I choose to place a new image in my Illustrator file and the window opens to let me choose a file to place, the "Date Modified" field of all the files in the folder I'm viewing (except other Illustrator files) quickly changes to the current date and time. This is definitely happening when I'm in Illustrator because when I needed files from a folder that had hundreds of images in it and I was able to select a file quickly, I was able to do so before it had changed the date on all of my files. However, when I needed a file from a folder that had hundreds of images in it but I took a long time to find the image I needed, Illustrator had time to change the date modified on all of my files. This might seem like an unimportant issue because it doesn't actually seem to modify or damage any of my files, but having all of the dates change on my files is a serious problem for my workflow and file management issues. So far, my only work around has been to use back-up image files, but that's not a long term solution and I don't understand why Illustrator should be modifying the dates of my files.
Is there a setting I can choose somewhere to prevent this problem? If not, is there somewhere I can report this kind of glitch? I'm not sure if I'm using the exact language necessary to get the issue across so please let me know if you have any questions! Thanks!

iCloud is not compatible with Snow Leopard, that is your problem.
A quick way out is to purchase Soho Organizer which is compatible, even when running on Snow Leopard, it will correctly handle Contacts and Calendars from iCloud. $100, 2 user license.
Soho Organizer
There is a free trial if you want to try it.

The date modified date for documents does not change

All my documents except for today and yesterday (whenever that happens to be) shows the date modified as being a random date of last year that is not when they were last modified. Does anybody know how to fix the problem so as the documents accurately show when they were last modified?

Go to website.
Change it back.
You will have 2 minutes to delete iCloud from iPhone.
Change it to new one on website and verify.
Sign in new one on the phone.

Copying files to my MBA Early 2011, 10.6.7 changes their 'date modified' to the current date. It happens only to some of the files copied. Any idea what my be causing it. Never had this problem before, on othe macs I have owned.

Copying files to my new MBA (early 2011) running 10.6.7 results in their 'modification date' to change to the current date. Any idea what may be causing it. It happens only to some of the files (there is no pattern to it.). I have not seen it previously in many other macs I have owned.

Hi all
I am bumping this thread again because I can't believe that I am the only one experiencing this issue. At times it is costing me hours repeatedly copying files until eventually the date doesn't show as modified.
I thought I had cracked it earlier by changing the Sharing & Permissions settings, and applying to enclosed items the ability for Everyone, Me and Staff fo have Read & Write permissions - but that doesn't seemed to have changed much.
Copying in smaller batches helps sometimes, but then other times it makes no odds, and the Date Modified date shows as the original date for a few seconds, only to change to today's date. Driving me nuts because there is no pattern to it.
Files which I have copied and show their original modified date, when moved to a subfolder, then have their date changed to today!!! Copying other files into the folder results in files that were previously OK having their Date Modified changed!
Am I on the only one?

Why doesn't Lightroom organise videos/photos lacking "date taken" by "date modified" instead of "date created"?

This still seems to be a problem with Lightroom 5. This post is one of the top results after trying to Google this problem, and it's for LR3. I can't understand why something so fundamental to video (and some photo) organisation has been overlooked for so long.
I've been trying to import and organise all my old photos and videos by date with LR5. They've been backed up and copied many times over the years, most recently to an external drive last week. So every file has a "date created" of last week. But "date modified" remains the original recorded date.
This doesn't matter for photos with a proper EXIF "date taken" - but LR5 looks at the "date created" for videos, making it completely useless for organising them into date-based folders. It puts videos I recorded in 2010 (as per "date modified") into a 2014-12 folder. Why.
It's not just a video problem - some photos I took with devices that didn't record EXIF "date taken" are also filed into folders from this month, even though the "date modified" on them is correct as being from 5 years ago.
How can I rely on LR5 for importing and date-based organisation when it relies on files (lacking "date taken") having never been copied or backed up?

Hello,
I use exiftool to modify the Creation and Modification time of the files. After that I use LR "Ajust time" feature to set the time of the movies in LR to the file creation time (last point). This works fine for me.
For MOV (Quicktime):
exiftool "-FileModifyDate<TrackCreateDate" "-FileCreateDate<TrackCreateDate"
For AVI:
exiftool "-FileModifyDate<DateTimeOriginal" "-FileCreateDate<DateTimeOriginal" *.avi
Depnding on your camera (and container format mov, avi) you may also ajust the time zone, e.g.
exiftool -FileModifyDate+=1 -FileCreateDate+=1 -if "$CameraModelName =~ /EOS 600D/i" *.mov
Which time in the container (MOV, AVI) you use as source, depends on your workflow. I edit my mov files before import. Therfore "CreateDate" is the time when I edited the file. Quicktime and (some) avi file contain a time when the containing stream was created. I use this vaule as source.
exiftool <filename> gives you detailed information about all available times.

'Date Created' changes to 'Date Modified'

Similar Messages

Maybe you are looking for