Finding Files by Date Modified

I need to be able to find all files in my Documents folder modified within the last weeek. (I need to be able to do this to back it up in Backup, which does not allow users to choose files by date modified.)
How is this done with Automator?
Much thanks!

Thank you so much for your help. It lead me to a solution!
I tried Smart Folders before, but Backup does not recognize them .
I am doing a weekly full disk image copy with Carbon Copy Cloner because I can't afford to be without all my stuff! I have an older used Mac on reserve in the event my hard drive (...) should crash. Should I my powerbook ever be out of service or need repair, I have a full backup of my entire disk image ready to go!
However, during the week I need to backup documents that I have been working on inbetween my weekly image copy. Unfortunately, Backup won't let me find and copy these files. Your solution with Automator (and the shell script) work great.
Thanks again!
Best regards,
Kurt Grossman

Similar Messages

  • Is Bridge supposed to sort raw files by date modified?  Not on my systems.

    I have just installed photoshop/bridge cs5 on two windows 7 systems, home premium 64 bit, one an i3 chip and the other an i7 chip.  I was formerly using cs3.
    I see that Bridge is not sorting my raw files by date modified like it did before.  It sorts jpg files okay.  I noticed that the xmp files associated with the raw files, when I hover over them in Windows Explorer show the correct modified date but the thumbnail icon shows only creation date, which I assume is as it shou ld be.  Why doesn't Bridge CS5 sort raw files by date modified as it did in CS3?  CS3 must have referred to the xmp file modified date to use for sorting, I would think.
    I should also mention that the metadata file does not show the correct date modified, but gives the same date as the creation date.  Also the thumbnails for raw images that have been modified correctly show the icon that indicates it was modified.
    Also, I see that when you hover over a thumbnail in Bridge CS5 nothing is revealed about the file.  In CS3 Bridge hovering over a thumbnail showed several pieces of data about the file including anything in the file info.
    Is this just how Bridge CS5 works or have I missed a setting somewhere in Bridge or Windows?

    Curt, thanks for your response.  The tool tips
    was not checked and did result in "hovering"
    working.  I'm not sure why that's called tool tips, but okay.
    I have just installed the software in the last
    few days.  I almost immediately got an update
    notice and installed the update.  I thought I was
    up to date.  Then, just a while ago I got another
    update notice.  After installing it the sorting
    now works.  Thanks much.  Problems seem to be solved.

  • Finder still says Date Modified = "Today" when it was actually 2-3 days ago

    I've been living with this bug for 3 years, always thinking that it was so obvious certainly Apple would fix it with the next revision. I can't believe that something so obvious could go on through three major OS revisions:
    In the Finder, the relative date "day" is often given as "Today" when in fact it was several days ago. You get the correct answer from "Get Info". Am I the only that has ever noticed this, or have all other Mac users simply learned to live with it?
    Here's a screenshot which shows this nonsense in action:
    http://www.sheepsystems.com/FinderDateBug.png
    Jerry Krinock
    Powerbook G4 1 GHz   Mac OS X (10.4.4)  

    How long did you have that "doue6tcj.default" Finder
    window open like that?
    About 2 minutes
    Long enough so that at one
    point in time, "Today..." was the proper date to be displayed?
    No
    If so, it sounds like what might be happening is that
    the display of the information about a file in the
    Finder is not not updating dynamically.
    Even though the answer was no, what you say is still true. The Finder is not updating dynamically as it obviously should.
    While the
    Finder does dynamically show the addition or deletion
    of files, probably for performance reasons, it won't
    check to see if a file has been modified until it
    "needs to", which is when you select the item.
    Selecting the item does not usually help. Also, I happen to know that there are simple API available to get the contents of a directory and their attributes, and given that < 100 items will fit in a window, this could be done in the blink of an eye.
    <div class="jive-quote">A couple of workarounds for this would be to hold
    down the up or down arrow key to quickly scan through
    and select each file. (Doing a Select All in and of
    itself doesn't cause the Finder to update information
    about all the items in the selection). Another option
    is to use Rainer's Nudge
    Contextual Menu to convince the Finder to update
    its display. For example, you could do a quick Select
    All, then control click on the selected files, choose
    "Nudge # items", and the display will be updated for
    all of the items.
    I hadn't heard about this utility, but its existence proves that this is indeed a problem which others have seen. We shouldn't have to install a third-party utility to fix a simple bug that has been around for three years.
    Mark, thank you for helping me to confirm this bug. I've now reported this bug to Apple, and encourage others to do the same! I'll end with this quote from Rainer Brokerhoff's web page, which explains one method which Apple could use to fix this bug:
    "In Mac OS X 10.3 (Panther), parity with FreeBSD 5 introduced the so-called kqueue mechanism...and the Finder doesn't use it. I suppose Mac OS X 10.4 (Tiger) will implement that..."
    That was dated Feb 14, 2005. Sorry, Rainer! Looks like you have the same misplaced confidence in Apple that I do.

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

  • Just opening InDesign file changes "Date Modified" date?

    Hi,
    Running InDesign CC w/ Mac 10.9.5 and if the file has say yesterdays date listed as the "Date Modified" in the file listing.
    If I just want to open the file just to take a quick look at the file without making any changes the "Date Modified" automatically changes to the exact time/date as opening the file.
    Why? I need the "Date Modified" to stay correct. 

    I've tried this experiment with InDesign 10 (CC2014) on my MacOS 10.9.5 system and do not see any changes to the OS modification date for the file. Same is true under Windows. And I tried doing some suspicious operations to the document such as printing and PDF export. Closed the document and checked the File Information. The Modification Date did not change. And it normally would not change unless you explicitly save the file. Anything else you are doing while reviewing the document? Again, we would like to help, but can't repeat your symptoms.
    BTW, an experiment to try is to “lock” the file using the MacOS Get Info dialog and then repeat your experiment. When opening the document in InDesign, you will see the window labeled as “read-only.” What happens when you subsequently close the document and look at the file modification date?
    And of course, I assume you are not confusing the file modification date with the “last opened” timestamp!
                 - Dov

  • Ordering files by date modified is not working

    Sorry for the print in Portuguese. Ordering by date modified (or any other date-based scheme) has worked until yesterday. Today all files are market as "no date" ("sem data" text in the print), although the all the file metadata is fine.
    Any suggestions?

    Curt, thanks for your response.  The tool tips
    was not checked and did result in "hovering"
    working.  I'm not sure why that's called tool tips, but okay.
    I have just installed the software in the last
    few days.  I almost immediately got an update
    notice and installed the update.  I thought I was
    up to date.  Then, just a while ago I got another
    update notice.  After installing it the sorting
    now works.  Thanks much.  Problems seem to be solved.

  • HT4796 cannot find files from data migration

    I have run the data migration utility and can see the user but files will not update.
    Jeff

    Look in /Users. If you ran Migration Assistant after the intial Setup Assistant, it tends to create a new user with your stuff in it.

  • Items "date modified" column when viewing files as list in finder

    I'm not really sure if I can change this viewing option, but i will give it a try:
    when viewing files as list in finder, "yesterday" items "date modified" column shows up with the term "yesterday", while this does not happen for "today" items, where what shows up is just today's date and not the term "today".
    I found this rather confusing, since it is not immediate: i.e. if I want to check for items modified today at a glance, i need to pick today's date from a ist with a number of different dates. As a matter of fact, it's a way easier when checking for yesterday's items.
    Suggestions anyone?
    Thanks!

    toygal wrote:
    I am new to Aperature and not very computer savvy so please provide "dummy's guide to" responses.
    toygal -- welcome to the Aperture user-to-user forum. iPhoto was designed with you in mind. Aperture is 100x more complicated (and no faster). I strongly recommend that you revert to iPhoto and use it. Compared to Aperture, it will bring you more pleasure and cause you much less frustration. Whoever told you that Aperture is faster not only was wrong, they failed to take into consideration the hours that you would have to practice to become comfortable with it.
    Here are some threads which briefly touch on the difference between iPhoto and Aperture -- use the search to find many more.
    http://discussions.apple.com/thread.jspa?messageID=13183439&#13183439
    http://discussions.apple.com/thread.jspa?messageID=12906017&#12906017
    http://discussions.apple.com/thread.jspa?messageID=12901779&#12901779
    Message was edited by: Kirby Krieger

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

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

  • Why a folder "Date Modified" doesn't reflect its latest modified files?

    Hello,
    I seem to not be the only one trying to find a solution to the following issue.
    Let's say you have a folder A, with different files/sub-folders in.
    When saving a file, the "date modified" of folder A doesn't update accordingly.
    It becomes a real nightmare when you need to backup tons folders and files, as you never know what has truly been modified, unless you dig in and open every single folder each time to check.
    For some reason, the folder A only updates its "date modified" when a file has been added or removed.
    Or, sometimes for some reason, folder A updates with the last opened, when who cares of that.
    I'm working on the latest Imac Intel puchased on dec 2012, with Mac OS X 10.8.4.
    If anyone can help, that would be great!
    Many many thanks!
    Loan

    Only the originator of a thread, the one who asks the question, can award points.
    If I understand your situation you have a folder that contains sub-folders that contain files and you want to see which sub-folder has the most recent file in it? Or more likely just find the most recent file.
    I would look at using a Finder smart folder to search and display the most recent file in a folder tree. Start the search at the top and just look for the most recent file.
    You might also, if you are on Mavericks, use the new tagging feature in some way. Say make a tag 'newest' and apply it  to the file you last modify, The drawback here is you would need to remove the tag from the last 'newest' file. Might not be to bad.
    regards

  • Date Modified in Finder does not update immediately

    I am finding that the Date Modified value takes several minutes to update in my Finder window when I've modified, saved and closed a particular file. Is there any particular reason for Finder not reflecting the the modified value immediately or any steps I can take to remedy this?

    I'm not 100% sure but when the finder window was constantly on the focus of the folder that contained the file in question, that's when the date would take time to update. However, since changing my workflow slightly, I now have several finder tabs open and I've found it changes immediately; or at least, it's updated as my focus has moved to another tab and then back to the tab containing the folder. Need more observation to confirm this though.

  • Finder Window - Date Modified Column Keeps Changing

    When I open a Finder window, change the size of the "Date Modified" column then close the Finder window, the next time I open the same Finder window, the "Date Modified" column will compress the size of the column.
    Why isn't Finder 10.9 maintaining my column changes?
    Any assitance or insight whould be appreciated.

    I solved the scrunched Date Modified column header in a similar fashion but added the Date Added field, which fixed the width of both Date columns.
    After doing so, I now find both Date-oriented columns display and read dynamically the actual date and time.
    I'm now looking for a solution to that issue, explained here:
    finder window date added date modified show date time always

  • Possible fix for Word2004 "Date Modified" issue

    I'm not sure if anyone else is still dealing with this problem - we discussed it a year ago here:
    http://discussions.apple.com/thread.jspa?messageID=7610823
    But just in case there's someone else out there with the problem - I think I've found a fix (requiring OSX Server 10.5, tested on OSX Server 10.5.6)
    The problem:
    When you have a Word 2004 file (whatever.doc) stored on a server (10.4.0-10.5.6) then you have an annoying Date Modified issue. Whenever someone who is not the owner simply opens the file, the Date Modified date updates. When the owner of the file opens it, the date does not change. So by simply opening the document (and making no changes, and not re-saving it) you trigger an update of the Date Modified field.
    More info can be found following the link above.
    Well. I think I've found a work-around that's better then the current "Have everyone login as the same user" one.
    In OSX Server, setup the permissions for the share with group as "read only" - so the POSIX permissions only give non-owners read-only access. (Everyone should also be RO or None)
    Then you need to apply a Custom ACL. You want to give them Read & Write, but then edit the Write permissions to not allow Write Attributes and Write Extended Attributes.
    So the ACL is:
    [ ] Administration
    [Y] Read
    [-] Write
    --[ ] Write Attributes
    --[ ] Write Extended Attributes
    --[Y] Create Files (Write Data)
    --[Y] Create Folder (Append Data)
    --[Y] Delete
    --[Y] Delete Subfolders and Files
    [Y] Inheritance
    Obviously this means your users cannot write attributes - so for photos and other files where meta-data is critical, this is not a great idea. But for the vast majority of shares, this is fine - they can still "read and write" all the files and folders, but the Date Modified problem does not arise.
    I'd be interested to see if this works for anyone else. Please let me know
    Charles

    Interesting and understood. I always tell people/clients that want to use dates either date created but definitely date modified to add that into the name of the file or call them revisions each time, ie:
    lawsuitJamesrev2
    or
    lawsuitJames_5_1209
    Reason being is depending on the backup system or worse yet disaster recovery you might not see or be able to see modified dates. IF the file is labeled as shown above it makes it easier. Again each person is different but from experience this works best as well as sorting. Also law firms I worked with have a number system since they needed to follow regulations on how to secure content. Again just ideas...hope you find an answer and pass it on

Maybe you are looking for