"Warning: Shifting of FileCreateDate not yet supported"

Started by tenthumbs, April 05, 2020, 03:00:23 PM

Previous topic - Next topic

tenthumbs

Hi.  I'm attempting to shift all file date/time info by +5 hours (flew off on vacation, forgot to adjust my camera's date/time for the first few days, now trying to fix that) and am getting this alert.  The syntax I'm using is:

exiftool -AllDates+=5 -FileModifyDate+=5 -FileCreateDate+=5 -overwrite_original .

I'm running this on a set of test files (about a dozen files) before trying it on a larger bunch of files.  The results I'm seeing initially appear to be accomplishing what I want - to simply shift all time values +5 hours.  Note that my goal is to time-shift ALL values, including all EXIF values and also the OS file-level ("Date Created" and "Date Modified") values.  Looking at the files in the Mac OS Finder, after running ExifTool using the syntax above, it does look like the "Date Created" and "Date Modified" values have indeed shifted by +5 hours.  So, it looks good initially.  However, upon closer inspection, I see a couple potential issues...

1. In the Mac Terminal app window, I'm getting this warning (once for each file):
Warning: Shifting of FileCreateDate not yet supported - ./P1277969.RW2
2. When I open the file in Photoshop, go to File > File Info, I see a number of unexpected values for "Date Created" throughout that panel (including values that seem to match neither the unmodified timestamp, nor the adjusted one, which leaves me scratching my head).

About my setup: I'm running ExifTool 10.74, on a Mac running MacOS 10.14.3 (and Photoshop CC, 20.0.3 Release).  Yes, I know, the OS is not up to date and the version of ExifTool is about 2 years old (so is the version of Photoshop).

First question...

The warning message I'm getting seems somewhat clear, but it's not clear to me WHICH "FileCreateDate" is 'not yet supported'.  Based on cursory observations, it appears that (the 'not supported yet' part) does not apply to the OS-level file data (because simply looking at the files in the OS (Mac Finder) listing, it sure looks like the Date Created and Date Modified were in fact shifted as I had wanted).  I'm assuming that what's not supported is an Exif value named "FileCreateDate" (and maybe another one named "FileModifiedDate", which I assume would exist).  Correct?

Second question...

I'm running an older version of ExifTool, not to mention an older version of the OS (and Photoshop, too - though I do have th very latest version of LightRoom, if that makes up for any of that).  If I update to the latest version of ExifTool, would that version address either of the two issues I'm seeing?  If so, I can get the newer version and run that.  But if the new version doesn't address that, then I see no reason to disturb what I have installed now, which seems to be (at least) partially working for me as-is.

Thanks for your guidance, and thanks for making this very useful tool available.

PS: To clarify my goal: I'd like all Creation/Modified dates to be adjusted by a few hours, so files "sort" correctly* at the OS level, and also appear/list correctly* in LightRoom.
* I define "correctly" here as the actual time of image capture, rather than what time my camera thought is was when the shutter fired. So they need to be shifted a few hours.
Nice-to-have, but not absolutely necessary, would be to have every single, deeply-buried Exif tag and other metadata corrected.  There are probably Exif values that I can drill down to see in Photoshop that I'll never care about, as long as they're not used for sorting purposes at a high level (eg once imported into LightRoom or visible in the OS listings).  It would be handy if I can get every value perfectly aligned to reality, but if some of that would require lots of effort to get right, I'd probably be happy enough just getting the most critical values right and moving on.

StarGeek

Quote from: tenthumbs on April 05, 2020, 03:00:23 PM
The warning message I'm getting seems somewhat clear, but it's not clear to me WHICH "FileCreateDate" is 'not yet supported'.

There is only one FileCreateDate and that is the one that is part of the operating system.  Finder is probably reading data from the embedded tags such as DateTimeOriginal.

Upgrade your version of exiftool.  The ability to write FileCreate was added in version 10.91 (See Version history) and requires setfile (see listing under Extra tags).
* Did you read FAQ #3 and use the command listed there?
* Please use the Code button for exiftool code/output.
 
* Please include your OS, Exiftool version, and type of file you're processing (MP4, JPG, etc).

tenthumbs

Thanks for the speedy reply.  I'll download the 11.93 update.  Two quick questions:

Is it necessary/recommended to uninstall a previous version (in my case 10.74) before installing a newer one?

QuoteThe ability to write FileCreate was added in version 10.91 (See Version history) and requires setfile (see listing under Extra tags).

The reference to setfile on the linked page is pretty brief.  Would my existing syntax (exiftool -AllDates+=5 -FileModifyDate+=5 -FileCreateDate+=5 -overwrite_original .) still be correct, or would I need to include some additional argument/parameter to correctly support setfile?

Many thanks again.

StarGeek

Quote from: tenthumbs on April 05, 2020, 03:50:55 PM
Is it necessary/recommended to uninstall a previous version (in my case 10.74) before installing a newer one?

Yes.  Uninstalling is simply the matter of just deleting the old version.  See last section under MacOS installing.

QuoteThe reference to setfile on the linked page is pretty brief.  Would my existing syntax (exiftool -AllDates+=5 -FileModifyDate+=5 -FileCreateDate+=5 -overwrite_original .) still be correct, or would I need to include some additional argument/parameter to correctly support setfile?

Setfile just needs to exist.  Exiftool will call it as needed.
* Did you read FAQ #3 and use the command listed there?
* Please use the Code button for exiftool code/output.
 
* Please include your OS, Exiftool version, and type of file you're processing (MP4, JPG, etc).

tenthumbs

OK, so I uninstalled, downloaded 11.93, installed that.  Running it again, I am seeing nearly the same behavior as before.  It appears to be shifting the OS-level "Date Created" value (also the "Date Modified" value) for all files (as viewed in the mac OS Finder) - same as before.  But it's still showing a similar warning - though the warning text string appears to be updated:

Previously, the warning was: Warning: Shifting of FileCreateDate not yet supported - ./P1277969.RW2

Now, the warning is: Warning: Shifting of MacOS FileCreateDate not yet supported - ./P1277969.RW2

Since the string is slightly different, I assume that suggests that the new version is actually running.  Though it appears it's still not behaving as desired.

I'm using this syntax: exiftool -AllDates+=5 -FileModifyDate+=5 -FileCreateDate+=5 -overwrite_original .

Have deleted the old build, restarted, etc.

Any ideas?

Thank you again for the help.

Phil Harvey

Yes.  Unfortunately this is one limitation of using an external utility to access the FileModifyDate.  You can copy to/from the FileModifyDate, but you can't shift it in place using +=.  However, there is a work-around:

exiftool -AllDates+=5 -FileModifyDate+=5 '-FileCreateDate<${FileCreateDate;ShiftTime(5)}' -overwrite_original .

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

tenthumbs

Thanks, Phil, for your reply as well.

Using this syntax:
exiftool -AllDates+=5 -FileModifyDate+=5 '-FileCreateDate<${FileCreateDate;ShiftTime(5)}' -overwrite_original .

That seems to work about as well as the previous try.  That is, it appears (to a cursory look) to have shifted the values as expected.  But it's still coughing up warnings, although a different warning now.  Here's the output:

Warning: Error 256 running "setfile" to set FileCreateDate - ./P1277969.RW2

One warning for each file processed.

As long as it's correctly shifting the time values, I can live with the warnings, but wonder if there's something amiss.  Am I doing anything wrong?

I'm wondering about this parameter:
'-FileCreateDate<${FileCreateDate;ShiftTime(5)}'
Does that value (5) need to have a '+' (or a '-') preceding it?

(I'm actually going to have to run this on two sets of files, one will need to be +1 and the other set will need -3...so I'm wondering if there needs to be a + or - specified)...

Many thanks again for the help!

Phil Harvey

This command works for me with no warnings.

If a minus sign isn't specified in the ShiftTime() call, then a positive shift is assumed.

When you run the "setfile" command in the Terminal, do you get this?:

% setfile
Usage: SetFile [option...] file...
    -a attributes     # attributes (lowercase = 0, uppercase = 1)*
    -c creator        # file creator
    -d date           # creation date (mm/dd/[yy]yy [hh:mm[:ss] [AM | PM]])*
    -m date           # modification date (mm/dd/[yy]yy [hh:mm[:ss] [AM | PM]])*
-P   # perform action on symlink instead of following it
    -t type           # file type

    Note: The following attributes may be used with the -a option:
        A   Alias file
        B   Bundle
        C   Custom icon*
        D   Desktop*
        E   Hidden extension*
        I   Inited*
        M   Shared (can run multiple times)
        N   No INIT resources
        L   Locked
        S   System (name locked)
        T   Stationery
        V   Invisible*
        Z   Busy*

    Note: Items marked with an asterisk (*) are allowed with folders
    Note: Period (.) represents the current date and time.
    Note: [yy]yy < 100 assumes 21st century, e.g. 20yy


- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

tenthumbs

Nope.  I get (what looks like) an error:

Note sure if I need to prepend the "setfile" command with that "%" character or not.  If I do, it returns this:

-bash: fg: %: no such job

If I simply type "setfile" in the Terminal window, I get this:

xcrun: error: invalid active developer path (/Library/Developer/CommandLineTools), missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrun


Am I missing some magic setfile juice?

IIRC, when I first went to use ExifTool (this was ~ 2 years ago), I had to install some Apple developer tools (Xcode or some subset of it).  At the time, I installed the required Apple developer stuff, and ExifTool 10.74, and got it to do what I wanted.  Today, at the suggestion of StarGeek, I uninstalled the older build of ExifTool, and installed the current one (11.93).  I have made no changes to the XCode installation.  Is it possible that ExifTool 11.93 requires some library or other component of XCode that would not be present/compatible with the newer ExifTool (in other words, to enable setfile)?  If so, what should I look for?

Thanks.

Phil Harvey

Quote from: tenthumbs on April 05, 2020, 09:43:48 PM
Note sure if I need to prepend the "setfile" command with that "%" character or not.

Sorry.  The "%" is the prompt in my Terminal window.

QuoteIf I simply type "setfile" in the Terminal window, I get this:

xcrun: error: invalid active developer path (/Library/Developer/CommandLineTools), missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrun

There is the problem.

"setfile" is installed with the XCode developer tools, so somehow this got broken.  You may be able to do this by typing "xcode-select --install" in the Terminal window.  You don't have to install all of XCode.

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

tenthumbs

Well I entered "xcode-select --install" in the Terminal window.  To my surprise, it asked if I really anted to install the command line developer tools etc, I confirmed, it went off to fetch the bits, downloaded and installed them (overall quite a good UX).

Then I tried: exiftool -AllDates+=5 -FileModifyDate+=5 '-FileCreateDate<${FileCreateDate;ShiftTime(5)}' -overwrite_original .

and that seemed to do the trick - with no warnings.  Woot!

A BIG thank you.

One last question to clarify...the files I've run this on were a test.  That seems to have worked.  Now I'll be running it two times, on two different sets of photos (a much larger set of files).  First set needs +1 hour, the second set needs -3 hours.  I assume that the correct syntax for each would be:

exiftool -AllDates+=1 -FileModifyDate+=1 '-FileCreateDate<${FileCreateDate;ShiftTime(1)}' -overwrite_original .

and

exiftool -AllDates-=3 -FileModifyDate-=3 '-FileCreateDate<${FileCreateDate;ShiftTime(-3)}' -overwrite_original .

for +1 and -3 respectively.  Just wanna confirm I have the positive and negative values correctly specified in all cases (the argument for ShiftTime doesn't need the "+" as it's implied, but does need the "-" explicitly, and my usage above is correct).  Those are correct, right?

Many thanks again for all the help and patience.

Phil Harvey

...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

tenthumbs

Awesome.

Thank you so much for the help and for this very useful tool!!!