Timestamp corruption intermittent bug

[bobbozzo]

Hi, I've been using exiftool.exe on Windows 8.1 (64-bit) from Windows .bat files for bulk modification of tags with -P, and am occasionally seeing the timestamps get mangled in the OS file properties.
(exiftool version 9.90 is what I've been using, but I will switch to the current version now.)

I call it as
t:\temp>exiftool-135mmLTII.bat *.orf

and the batch file looks like:
exiftool.exe -P -LensModel="135mm Rokkor-X MD + LTII" -Lens="Minolta 135mm f2.8 Rokkor-X MD + LensTurbo II" -Fnumber="2.0" -FocalLength="95" -Focal
LengthIn35mmFormat="190" -overwrite_original *.orf

SOMETIMES, 1 or more of the modified files will have timestamps with dates of 1601-01-01 (see screenshots). Note this is in the Windows NTFS file properties, not the EXIF data.
Because of this, programs have trouble with the files (RawTherapee won't open the files, XnViewMP won't show properties or build a new thumbnail, ...)

Correcting the timestamps with TotalCommander seems to fix the problems.

[bobbozzo]

My camera is an Olympus E-M1 (mk1) with firmware 4.1.

Also, the problem is not reliably reproducible; running the same command on a backup of the same file does not often cause it to happen again.

[Hayo Baan]

This is odd. Exiftool uses the OS to set and maintain the modification date. So if anything goes wrong with that, like you show us here, then I suspect something else is at play. Especially since you say it happens inconsistently, even on the same file.
What anti virus software are you running? Perhaps that's interfering here?
I'm also curious to see what the original modification date is and what happens if you do not use overwrite original.

[bobbozzo]

Hi,
A/V is Avast.

I do other operations like this, and have not seen it happen before:
with TotalCommander (I have it set to preserve file mod date (but not create date) on file copy/move)
with MP3 tools such as MP3GainGUI (preserve datetime)

I've been using this computer and OS install for 3.5 years... I just searched my system for other files older than 30 years and didn't find any other than some more .ORF files from 1601 (ones I had used exiftool on previously).

I guess I can start using it without overwriteoriginal.

BTW, it happens infrequently enough (and I don't use it frequently either) that it's going to be hard for me to reproduce.
Perhaps other can check their systems... in Windows Search you can enter
date:1601
to find files with this issue.

[bobbozzo]

BTW, the date is always 1601-01-01, but the times vary... they do not match the original times, but when it happens to more than one file at once they do all have the same times.

[Phil Harvey]

Very odd.  ExifTool will report any error when using the system date/time routines to update the file times, so if you didn't get any warnings then the times were written properly as far as ExifTool is concerned.  I agree with Hayo... the problem is likely an antivirus interference.  If the AV is too aggressive at checking new files it can prevent ExifTool from functioning properly (although I would expect an error here, and I haven't seen this particular type of failure).  If you can add an exception for files written by ExifTool, try that.

- Phil

[bobbozzo]

OK... I've added an A/V exclusion for my photos drive.

(No errors have been reported that I've noticed, and I do always run it from a shell so I'd likely see them)

Thanks!

[StarGeek]

Perhaps other can check their systems... in Windows Search you can enter
date:1601
to find files with this issue.

Just ran this search on my main image drive and no results.  -P -overwrite_original are default options on everything I do with exiftool.

Turns out that In Windows systems (in NTFS or Active Directory) the start date is 01/01/1601.  But I can't find anything on google where a similar timestamp error has happened.

[bobbozzo]

I now believe it's XnView MP that's primarily causing this, on file move, and not ExifTool.

Sorry & Thanks!