File date modified on imported pictures

Hello,
I have imported a large number of pictures into iPhoto '08 from an external hard disk. Then I have checked the content of the "Originals" folder into the iPhoto Library. Some pictures have their file date changed to the date of the importation. I am not talking about the EXIF data but the files themselves.
All the pictures stored on my external hard disk have their file date set to the date of the shot. This is normal because I have transferred them from the camera to the disk then I have not modified them.
Do you know why iPhoto has changed the date of some of my pictures? Everything is fine for 99% of them, it happened only on the last pictures but I have not changed the way I transfer them...
I know that this is not a big deal because I can see the original date into iPhoto but I like to see it directly from the Finder when looking at file details.

LarryHN wrote:
Not weird at all - this is because when you import a photo into iPhoto it is copied into the originals folder - a new copy is "created" which of course sets that time as the "creation" time. The creation date is "when the finder created the file" - not at all weird
I understand and it sounds logic. But why are the other 99% of my pictures unaffected then?
Although this is probably relatively safe - I see no advantage to changing the creation date of the files since iPhoto ignores it and uses the EXIF date - and any time you make any change to any file within the iPhoto library you are risking corruption of the library
I synchronize the "Originals" folder with a Windows PC and I browse the pictures with the file explorer on that one... in "Details" mode. So, it is nice to see at first sight in the files list when the picture has been taken.
I know, it's not a big deal...

Similar Messages

  • Commit issued , but physical file date modified still

    Hi,
    i have update a record and commit
    i am still see all the files in my db with the same modified date like before the update
    if i shutdown the db , everything get updated
    how is that , i ithink Redo logs should be written immediately after commit , otherwise an electricity outage will make this committed transaction lost
    thanks

    Hi Anand,
    but when i commit ,
    no file have been change , even the redo log date modified is still the same. so where oracle writes the data....
    or it writes in redo log file and for some reason , redolog file date modified don't change??!!!!!

  • Original video file date changes when imported

    When I import video files, the date of the original source file gets changed to the date of my importing it.
    Premiere Pro CS4 never did that. Why is CS5.5 changing the date of the source file ??
    steve

    Hi Todd, --
    I think you are saying my 'write xmp id to files on import' must be turned ON somehow. I did not do that, so if it is turned ON, it must be ON by default ?
    It was both 'date created' AND 'date modified' that were being changed to the date of import.
    Ok, I found that. It is turned ON by default, I turned it OFF. I also turned OFF the next one too - 'enable clip and xmp metadata linking'.
    I just did a test import, and the 'date modified' of the video files on the hard drive has not changed. Thank you.  VERY MUCH.   
    But, I have other problems too, with PP, and video file dates.
    There's a 'date created' and a 'date modified' for video files. Plus, with Windows 7, there's a few more dates - 'date of content' etc.
    My original untouched video file dates do not make any sense. 'Date Modified' is showing the date the video files were recorded. 'Date Created' is showing the date I copied the video files from the camera stick to the hard drive.
    That makes no sense. They should be the reverse.
    Why why why after 30 some odd years have the computer engineers NEVER made video files dates the same as digital photo files, with 'Date Taken'.
    Also,
    I have multiple cameras. For each event or trip or whatever I often take several 1,000 photos and videos. It's an absolute necessity to be able to mass import chronologically. The only way I can integrate / import them all in chronological order is by Date originally Taken, and then immediately drag all the files to the timeline while they are still all collectively highlighted in the order I just imported them all by date.
    PP only allows for imports by 'date taken' for photos and 'date modified' for video files. And, if I don't immediately drag the imported files to the timeline while they are all still highlighted without doing anything else first, the bin window re-arranges them all by filename, and there is no way to later re-arrange them by dates.
    This is extremely aggravating and impossible to work with for my need to import then later work with multiple-source recorded files chronologically.
    All these 'date' problems for video files really totally screws that.
    steve

  • 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/

  • How to show time as well as date in Finder for file Date Modified

    Completely mystified... Folder is only showing the mm/dd/yy modified for any file not modified Today (which then says Today and the time).
    Why on Earth would the Date AND TIME not show for all files? I can't seem to find any option to do this. Definitely want a way to:
    o make the change globally (not folder by folder)
    o and extra credit if i can get four digit years showing too.
    Complete mystery why this isn't the default view or maybe I did something inadvertantly to make things easier for people who don't want too much information. (?)

    Try this:
    Double click the Macintosh HD on the desktop > Cmd + J > Check the buttons you want concerning the date and time > press the button Use as default. Hopefully it will rub off on all the other folders too!

  • PLEASE HELP!! Why do my file dates change on import?

    I'm trying to drag and drop iPhotos into Aperture or export a collection of files and then import them into Aperture, but the image date changes to a random date in the future when I do so.
    What am I doing wrong?
    How do I solve the problem?

    hi, jan
    quote: "Hmmm... the "Edit" button works for me, but it looks like the data I changed didn't actually change... even though the modified date on the .jpg file updated..."
    I've been wanting to change the exposure EXIF data since I started using Aperture to make a 32bit HDR file from one photograph so as to fake bracketing of multiple photographs (with just one photo) and obtain a perfect exposure of difficult shots like forests, night city scenes, night clubs etc.
    Back to the drawing board
    Thanks for your help
    victor

  • Unreadable File when trying to import Pictures from CompactFlash in Reader

    In the past I have been able to read images from my compactflash.
    This just started happening.
    I have a Canon EOS Rebel and it stores images on a CompactFlash. When I put it in my Dazzle* Hi-Speed USB 2.0 reader to download the images into iPhoto, I'm getting "unreadable file" errors. Then I take the same reader and flash card to my Windows laptop, I'm able to read the images. Then I figure.. what if I manually copy the pictures to a folder on the Mac... Well, they copy over, and if I single click the file when my finder is on Column mode, the thumbnail of the image comes up in the Preview pane, but when I double click it for Preview Application to open, the image comes up digitally corrupted. Even if I take my USB cable that came with the camera, I put the flash back into the camera and then I try to download the images and still get the same error.
    I HAVE TO FIGURE OUT A WAY TO GET MY PICS TO IPHOTO!!
    So, I scaled down the capture from LARGE to SMALL, and tried to read the files from the reader again. I GET THE SAME ERROR! Then I try the USB Cable direct to the camera, and lo and behold, iPhoto is able to pull in the pictures.
    My question is... Has anybody out there experienced CompactFlash card reader problems? You think this is a Tiger problem?
    PS.. I've tried reformatting the flash using the OS from the Camera, and with Windows OS with no success.
    Thanks in advance!

    Thanks for the reply...
    When I was experimenting, I copied the files from the reader unto the mac, discovered I couldn't read it, then from the Windows computer, I networked over to the Mac to attempt to view the images. It was corrupted, that's when I went on a wrong tangent.. and started blaming the camera. I foolishly formatted the card, erasing the good images. So, now I'm left with bad images on the Mac because, I missed the opportunity to copy the images unto the windows laptop with the reader. There weren't that many pictures, but darn... we could've used one of them for our XMAS card.
    This experiment still begs the question, "How come the reader can work on the windows computer and not the Mac?" but, life is short... readers are cheap, I'll just buy one just like the one I borrowed... that works, on the Mac, and keep the other reader on the Windows computer with a sign that says "Doesn't work on Mac!".
    But just curious, what is a "kext file"? Is that a driver?

  • Date modified is incorrect on exisiting files?

    Hello all - We have a NW 6.5 SP8 server with Win7 and XP clients. All clients though report the existing shared files date modified attribute incorrectly (31/12/1984). This applies to all files - folders seem to be ok. Create a new file and it's fine. Copy and paste an existing file and the modifed date will remain the same (1984) but the created date will be the current time and date.
    I've had a good search and the small mentions of it point to it being possibly an AV or backup issue? There's no AV on the NW server (not ideal I know but it is on all the Windows servers) and I don't "think" it's anything to do with backup either (but I will check/investigate further)
    Has anyone any ideas please?
    Many thanks

    Originally Posted by HvdHeuvel
    On Tue, 14 Aug 2012 22:46:02 +0000, ataubman wrote:
    > Always an AV or backup issue, in my experience. Is there AV on the
    > clients?
    >
    > Also: has this always happened, or only since what change or update?
    The OP most likely have Windows XP Clients with A/V software installed
    (Sophos ?)
    After scanning mapped network drives from the Workstation, the dates of
    the files on the network drives have been reset to 1985.
    This problem has been introduced with an update to the A/V software that
    has invalidated the check that was in place for this in the Novell client.
    We have now made another update to the client, which can be downloaded
    from here [1] :
    Few customers have already confirmed this to be the solution to the same
    problem
    Regards
    Hans
    [1] NOVELL: Downloads - Novell Client 4.91 Post-SP5 (IR1) NWFS.SYS 3
    Thanks for this Hans, much appreciated.
    Yes - well guessed, Sophos on the clients. Mostly clients are Win7 though - is there a recommeded client for Win7 that has been customised to avoid this issue?
    If I install the client you posted on the XP machines will it rectify this issue, as in will the dates be reset with the correct data - or is that modified tag info missing for ever?
    Thank you so much for taking the time to help!
    Echo

  • I am trying to change the date on an imported home video clip. I entered 9/7/2012 and got 6/9/0339! I checked modify original file, but it is not working. Any ideas?

    I am trying to change the date on an imported home video clip. I entered 9/7/2012 and got 6/9/0339! I checked modify original file, but it is not working. Any ideas?

    Are you using the Adjust Date and Time option or the Batch Change option?  If it's the former try the latter.  If you get the same results  launch iPhoto with the Option key held down and create a new, test library.  Import  the same video file and check to see if the same problem persists.
    OT

  • "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

  • Is there a way to tell if the date on a picture in iPhoto is from actual metadata vs just the date it was imported to the program?

    I have many photos in iPhoto whose dates I know to be wrong and many appear to be the date I moved them all to a new Mac. I photos in question, I think, were originally on a PC and in Picassa. If it was taken before metadata was embedded, I suppose I can just guess and change the dates on the photos however, if iPhoto just applied the date of the transfer to the Mac, perhaps there is accurate metadata somewhere that I could retreive. How can I tell where iPhoto is getting its dates for pictures?
    Thanks,

    If the Exif metadata is intact, then iPhoto gets the date from there. If it's not, then iPhoto gets the file date.
    So, if iPhoto is showing you the date of import there is no Exif intact.

  • How do I import pictures from computer files more than one at a time ?

    I recieved the adobe photoshop elements 10 for x mas and no problems with downloading the program but i am having a time importing pictures from my computer files taken from various camaras. the problem is that i can only import pictures from my files 1 at a time. what do i do ? is there a specific tutoral i need to watch ? I know i'm doing something wrong i just don't know, please help Kev

    Welcome to the forum.
    You should be able to use the Shift, or Ctrl modifier keys, to select multiple files, and Import them.
    Now, for Stills, I would strongly suggest that you Scale those Still Images to about the Frame Size of the Project, prior to Import.
    Good luck,
    Hunt

  • In my opinion, the real solution is for Apple to offer us a choice of the photo sort order in ITunes. My preference would be filename, perhaps with options to choose the Date Taken attribute, file timestamp or date modified filestamp (EXIF date fields as

    I tryed to sort my pictures with buying Apps and following suggestion from apple, but without any success. In my opinion, the real solution is for Apple to offer us a choice of the photo sort order in ITunes. My preference would be filename, perhaps with options to choose the Date Taken attribute, file timestamp or date modified filestamp.

    Not a problem when using iPhoto on a Mac, which the transfer of photos is primarily based on - not manually managing photo storage as seems to be common with Windoze.
    The same should be available with a supported photo management app on a PC.
    http://support.apple.com/kb/HT4221

  • Can't import pictures I once could  Unrecognized file type

    I recently had to reinstall some system software because my computer wouldn't reboot. When I opened up iPhoto 5 nothing was there. I went to a back up and imported the latest Librarty. When I went to import the rest of the photos I got this error message... "The following files could not be imported (they may be an unrecognized file type or the files may not contain vallid data)." All my pictures are the same file type and size and come from the same camera. They all open in the Preview application.

    Diane
    Are they in the iPhoto Library Folder? Because iPhoto wont import pics from the iPhoto Library Folder - a precaution against duplication. Drag them to the desktop and try again.
    Regards
    TD

  • InDesign will not open files in Date Modified order

    I have never had this problem before, but suddenly InDesign will not import/open my files (photos) in Date Modified order. No matter how I select the files or order/arrange the files in the File\Place window, they open in name order. I have 200 separate folders with six photos each. These are to be placed in the InDesign document in date modified order. Someone suggested batch renaming the files using Adobe Bridge, however the files are in 200 individual folders for a reason and I don't want to open each folder and batch rename 6 at a time. I have reset my InDesign preferences with no luck. I am using Version CS5.5 of InDesign, Mac OS X 10.7.5. Any suggestions?

    @Emily,
    It usually only confuses a discussion to open a new thread on the same subject.
    I'm directing you back to the original discussion you opened earlier today instead of starting another one:
    http://forums.adobe.com/thread/1292390?tstart=0
    I'm also locking this discussion.

Maybe you are looking for