Hello, I'm new to working in Terminal, so I'm a real newbie. I need to change the CreateDate and clear the ModifyDate in a PDF. Using ExifTool, I was able to locate the PDF in Terminal, but I don't know how to do the next step(s): give the command to change the CreateDate to an exact one I have in mind. (For this command, let's just say I want to change the date to February 4, 2024.). Additionally, I would like to have the "ModifyDate" be blank. Could someone please help with these commands? THANK YOU!!
The question is which "create date" and "modify date" are you trying to change, as there are multiple tags that fall under these names and different programs will read different ones. For example, if you are checking the dates from the desktop, then odds are you are seeing the file system time stamps, while viewing it with a PDF program, you are probably seeing the dates that are embedded in the file.
Run this command to view all the date/time tags in the file
exiftool -time:all -G -a -s file.pdf
Compare the output to what you are seeing elsewhere to figure out the name of the tag you want to edit.
Using your example date/time, your basic command would be something like, assuming you want to change the file system time stamps.
exiftool -FileCreateDate="2024:02:04 12:00:00" -FileModifyDate="2024:02:04 12:00:00" file.pdf
Note that most date/time tags require a time as well as a date. Also, there are tags, like the above file system ones, that cannot be removed.
To try and remove a tag, you would take the tag name and set it to be blank. For example, if you were trying to remove the embedded ModifyDate, you would use
exiftool -ModifyDate= file.pdf
One very important thing to understand is that any change made to a PDF by exiftool is reversible. Exiftool uses the incremental update (https://www.debenu.com/kb/incremental-updates/) property of PDFs which does not clear the previous data. To make the changes permanent, you have to use a program to re-liniarize. The PDF Tags page (https://exiftool.org/TagNames/PDF.html) gives an example using the command line program, QPDF (https://qpdf.sourceforge.io/).
Hi, thanks so much for your reply.
I tried running the command after identifying my file (using the command:
exiftool -a -G1 -s d [path/my file name].pdf
and it gave me this:
Warning: Error 256 running "/usr/bin/setfile" to set FileCreateDate - [path/my file name].pdf
It then said "one image file updated", but when I checked my doc (viewing the File->Properties) nothing had been changed.
Can you please advise?
From a previous post
Quote from: Phil Harvey on May 02, 2020, 07:03:03 AMNote that you need the "setfile" utility on MacOS to set FileCreateDate. You can install this with "xcode-select --install".
The FileModifyDate should have been changed, but you'll need to install "setfile" to be able to change FileCreateDate.
- Phil
Hi Phil!
I guess I'm too much of a newbie. I don't know how to install the Setfile utility (tried pasting your command into Terminal and nothing happened).
I've spent the better part of today trying to figure out how to change the dates on my PDF - I think I may give up before I get too frustrated.
Though I do appreciate your help.
Hello Phil thank you for your valuable tool and advice, I registered to report/request your input on a similar problem on macOS Sonoma 14.7.1 (Intel) after encountering a "setfile" error despite updating to the latest ExifTool v13.00 just now. Xcode command-line tools were installed fine, /usr/bin/setfile exists.
Instead of creating a new thread, I take the liberty to continue this one:
% exiftool -G1 -a -s -time:all *mkv
======== My.mkv
[System] FileModifyDate : 2024:10:24 09:27:07+03:00
[System] FileAccessDate : 2024:10:24 09:27:07+03:00
[System] FileInodeChangeDate : 2024:11:01 15:45:33+02:00
[Matroska] DateTimeOriginal : 2024:10:24 06:27:07Z
% xcode-select --install
xcode-select: note: Command line tools are already installed. Use "Software Update" in System Settings or the softwareupdate command line interface to install updates
% whereis setfile
setfile: /usr/bin/setfile
% exiftool "-FileCreateDate<DateTimeOriginal" "-FileModifyDate<DateTimeOriginal" -ext mkv -ext MKV *mkv
Warning: Error 512 running "/usr/bin/setfile" to set FileCreateDate - My.mkv
1 image files updated
Any idea what could be causing this error? I have not had issues with past versions (and macOS) to be honest, cannot remember when this started.
Many thanks in advance.
What is the result if you run this command? Does it update the FileCreateDate?
/usr/bin/setfile -d '01/02/2000 03:04:05' My.mkv
- Phil
Hello Phil (pleasure to make your acquaintance) yes it looks like it:
% ls -lAG *pdf
-rw-r--r-- 1 konsti staff - 103647 Oct 31 10:11 report.pdf
% /usr/bin/setfile -d '01/02/2000 03:04:05' report.pdf
% /usr/bin/setfile -m '01/02/2000 03:04:05' report.pdf
% ls -lAG *pdf
-rw-r--r-- 1 konsti staff - 103647 Jan 2 2000 report.pdf
% % stat -f "Access (atime): %Sa%nModify (mtime): %Sm%nChange (ctime): %Sc%nBirth (btime): %SB" report.pdf
Access (atime): Nov 1 16:11:11 2024
Modify (mtime): Jan 2 03:04:05 2000
Change (ctime): Nov 1 16:10:55 2024
Birth (btime): Jan 2 03:04:05 2000
% SetFile -h
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
[...]
I checked in Finder and both Creation and Modification dates are at the date you provided.
File permissions is not an issue, by the way (I have write access obviously).
And "SetFile" (yes with caps...) seems to be OK in the date formatting you requested me to test (as I am in Europe, thought of checking too...)
P.S. Not sure this error "512" if it's a macOS error, or ExifTool error or SetFile error to look for its meaning...
Hmmm. OK. So setfile seems to work.
The next step would be to try running it from perl:
perl -e "system(q(/usr/bin/setfile -d '06/07/2005 08:09:10' My.mkv))"
- Phil
Works, too, Phil...
% perl -e "system(q(/usr/bin/setfile -d '06/07/2005 08:09:10' My.mkv))"
% perl -e "system(q(/usr/bin/setfile -m '06/07/2005 08:09:10' My.mkv))"
% stat -f "Access (atime): %Sa%nModify (mtime): %Sm%nChange (ctime): %Sc%nBirth (btime): %SB" My.mkv
Access (atime): Nov 1 17:14:36 2024
Modify (mtime): Jun 7 08:09:10 2005
Change (ctime): Nov 1 17:15:09 2024
Birth (btime): Jun 7 08:09:10 2005
Works equally on "report.pdf" (could not make it run in some more "verbose" mode, not sure it exists for such Perl use? No error in Terminal).
Remember I am running Sonoma 14.7.1, perhaps some security issue? Accessing something that's now forbidden?
OK. There are 3 possible things left that could be the problem.
1. Some security thing. I don't really understand quarantines, but use this command to see if exiftool is quarantined:
exiftool -xattrquarantine /path/to/exiftool
If this is the case, try deleting the quarantine:
exiftool -xattrquarantine= /path/to/exiftool
2. ExifTool is somehow passing the incorrect date/time format to setfile. I think this is unlikely because we would see this on other systems not just Sonoma.
3. Something related to the case of "SetFile" vs "setfile". Are you using a case-sensitive filesystem?
- Phil
1. No extended attributes nor quarantine at all:
% exiftool -xattrquarantine /usr/local/bin/exiftool
% xattr -r /usr/local/bin
No results i.e. clean; checking permissions and ownership, just in case:
% ls -lAG /usr/local/bin
total 158664
-rwxr-xr-x 1 root wheel - 334016 Oct 24 18:03 exiftool
-rwxr-xr-x 1 root wheel - 78862176 Dec 31 2023 ffmpeg
drwxr-xr-x 4 root wheel - 128 Feb 2 2018 lib
-rwxr-xr-x 1 root wheel - 1592144 Apr 19 2022 pdfinfo
lrwxr-xr-x 1 root wheel - 28 Oct 25 2023 pdftk -> /opt/pdflabs/pdftk/bin/pdftk
-rwxr-xr-x 1 root wheel - 440168 Feb 26 2024 unrar
3. I've never ever used Case-Sensitive FS during my years on MacOSX and macOS:
% diskutil info /Volumes/Samsung | grep 'User Visible'
Name (User Visible): APFS
2. Mind you, the mkv files DO GET their timestamp changed; it's just the error that's in the output of the process. Perhaps you missed that in my original message? I saw the MKV and PDF tested that they had the Modification/Creation time changed, just that the error "512" was also appearing before "X image files updated".
Moreover, as I mentioned earlier, I did run the SetFile (or setfile) with the -h parameter to see the date formatting, so no change there either being in EU (i.e. mm/dd/[yy]yy [hh:mm[:ss] [AM | PM]] ) which I assume ExifTool does comply to (as it's been working for my HEIC and JPEG's) already (and without any error).
Oh, well. We can live with the error I guess...
OK. I missed that ExifTool actually was setting the FileCreateDate properly.
I wonder if setfile is somehow just returning an erroneous error code.
What happens if you do this:
/usr/bin/setfile -d '01/02/2000 03:04:05' My.mkv
followed immediately by
echo $?
This will show the return code from setfile.
- Phil
No error Phil, returns zero (clean exit).
% /usr/bin/setfile -d '01/02/2000 03:04:05' My.mkv; echo $?
0
% /usr/bin/setfile -d '01/02/2000 03:04:05' My.mkv
% echo $?
0
The date format is correct, right? (intentional I guess).
Perhaps something inside ExifTool when it calls SetFile? I am a power user but can't decipher your code, unfortunately.
I have created some time ago a few aliases in my .zprofile for easier file management, e.g.
alias exifmov="exiftool -v -m '-FileCreateDate<("$"CreationDate+"$"(date+'%z'))' '-FileModifyDate<("$"CreationDate+"$"(date+'%z'))' -ext mov -ext MOV ."
alias exifdate="exiftool -v -m '-FileCreateDate<DateTimeOriginal' '-FileModifyDate<DateTimeOriginal' -ext jpg -ext JPG -ext HEIC ."
alias exiftiff="exiftool -v -m '-FileCreateDate<CreateDate' '-FileModifyDate<ModifyDate' -ext tif -ext TIF ."
alias exifjp2="exiftool -v -m '-FileCreateDate<CreateDate' '-FileModifyDate<ModifyDate' -ext jpf -ext jp2 ."
alias exifpng="exiftool -v -m '-FileCreateDate<CreateDate' '-FileModifyDate<CreateDate' -ext png -ext PNG ."
alias exifmkv="exiftool -v -m '-FileCreateDate<DateTimeOriginal' '-FileModifyDate<DateTimeOriginal' -ext mkv -ext MKV ."
alias exifmp4="exiftool -v -m '-FileCreateDate<MediaCreateDate' '-FileModifyDate<MediaCreateDate' -ext mp4 -ext MP4 ."
alias exifname="exiftool -v -m '-FileName<DateTimeOriginal' -d '%Y-%m-%d %H.%M.%S%%-c.%%e' -ext jpg -ext JPG ."
...but it only happens for MKV's, I tried again JPG, HEIC and iOS MOV file just to see if Sonoma 14.7.1 or ExifTool 13.00 also show this error.
(the error happens with either alias or the real command, I tried the actual command line before posting)
UPDATE: Error "512" happens for PNG's too...
% exiftool -v -m '-FileCreateDate<CreateDate' '-FileModifyDate<CreateDate' -ext png -ext PNG .
======== ./Asus OpenVPN Settings.png
Setting new values from ./Asus Boulogne OpenVPN Settings.png
Warning = Error 512 running "/usr/bin/setfile" to set FileCreateDate
Warning: Error 512 running "/usr/bin/setfile" to set FileCreateDate - ./Asus OpenVPN Settings.png
1 directories scanned
1 image files updated
Quote from: konsti on November 01, 2024, 09:59:01 AMWarning: Error 512 running "/usr/bin/setfile" to set FileCreateDate - My.mkv
1 image files updated
Any idea what could be causing this error? I have not had issues with past versions (and macOS) to be honest, cannot remember when this started.
I noticed that "Warning: Error 512 running "/usr/bin/setfile" to set FileCreateDate" after upgrading to macOS Sequoia 15 and Xcode 16. In earlier macOS Sonoma 14.7 and Xcode 15.3 that message does not occur.
But in my setup the output is still as expected also with macOS 15.0.1 and Xcode 16.
For example (https://exiftool.org/forum/index.php?topic=16580.msg89089#msg89089) there is that warning when copying .xmp sidecars to .jpg. That warning could be fixed by editing time zone off from the .xmp sidecar. For example edit...
<photoshop:DateCreated>2000-01-01T12:00:00+02:00</photoshop:DateCreated>
...to:
<photoshop:DateCreated>2000-01-01T12:00:00</photoshop:DateCreated>
...then there is no such setfile warning. ...but then in my command is "Warning: Error converting value for ExifIFD:OffsetTimeOriginal (PrintConvInv)" because the time zone Offset is missing from the .xmp and I am trying to copy it...
- Matti
Ah ha! So the problem could be that the new setfile doesn't like having a timezone added. If true, this should produce an error code:
/usr/bin/setfile -d '01/02/2000 03:04:05+06:07' My.mkv
echo $?
If this does then I'll add a patch to remove the time zone. (Note that this still returns 0 on my Mojave system.)
- Phil
Quote from: Phil Harvey on November 01, 2024, 01:37:06 PMthe problem could be that the new setfile doesn't like having a timezone added
Yes, that seems to be the case:
/usr/bin/setfile -d '01/02/2000 03:04:05+06:07' a.jpg
echo $?
ERROR: invalid time (expected hh:mm[:ss] [AM|PM])
2/usr/bin/setfile -d '01/02/2000 03:04:05' a.jpg
echo $?
0For some reason some commands succeed to change FileCreateDate while some commands fail if trying to copy a date with a time zone.
- Matti
Perhaps the Sonoma 14.7.1 update follows the new Sequoia mentality and the SetFile date formatting but it is idiotic to remove support for timezones!
Again on my "latest" Xcode command-line tools, the format in SetFile -h reports:
% setfile -h
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
[...]
...without any mention to timezone indeed... so I guess we will have to deal with the computer's own timezone %z Phil?
That is what I had added in my .zprofile alias for MOV files, after searching the forum here sometime ago:
alias exifmov="exiftool -v -m '-FileCreateDate<("$"CreationDate+"$"(date+'%z'))' '-FileModifyDate<("$"CreationDate+"$"(date+'%z'))' -ext mov -ext MOV ."
For the record, doubt that a timezone of +06:07 exists so I tried with +06:00 just to be on the safe side, and still fails.
% /usr/bin/setfile -d '01/02/2000 03:04:05+06:00' report.pdf
ERROR: invalid time (expected hh:mm[:ss] [AM|PM])
% echo $?
2
Quote from: konsti on November 01, 2024, 05:23:56 PMFor the record, doubt that a timezone of +06:07 exists
But time zones of xx:30 (India for example) and xx:45 (Nepal) do exist, so it would have to be able to handle those at least.
Indeed, but was just checking if it was hard-coded in SetFile command, StarGeek. You never ever know..
Quote from: konsti on November 01, 2024, 03:34:25 PMPerhaps the Sonoma 14.7.1 update follows the new Sequoia mentality and the SetFile date formatting but it is idiotic to remove support for timezones!
On the other hand file dates are UTC so I guess they do not use time zones anyway?
But currently the following command fails to update FileCreateDate because it tries to copy time zone:
exiftool -a -G1 -s -api QuickTimeUTC=1 -FileCreateDate -FileModifyDate -CreateDate -CreationDate movie.mp4
[MacOS] FileCreateDate : 1999:06:01 12:00:00+03:00
[System] FileModifyDate : 1999:06:01 12:00:00+03:00
[QuickTime] CreateDate : 2024:06:01 12:00:00+03:00
[Keys] CreationDate : 2024:06:01 12:00:00+03:00
exiftool -overwrite_original -api QuickTimeUTC=1 '-FileCreateDate<CreationDate' '-FileModifyDate<CreationDate' movie.mp4
Warning: Error 512 running "/usr/bin/setfile" to set FileCreateDate - movie.mp4
1 image files updated
exiftool -a -G1 -s -api QuickTimeUTC=1 -FileCreateDate -FileModifyDate -CreateDate -CreationDate movie.mp4
[MacOS] FileCreateDate : 1999:06:01 12:00:00+03:00
[System] FileModifyDate : 2024:06:01 12:00:00+03:00
[QuickTime] CreateDate : 2024:06:01 12:00:00+03:00
[Keys] CreationDate : 2024:06:01 12:00:00+03:00FWIW FileCreateDate can follow FileModifyDate
backwards in time which obviously explains why despite the error the same command works here as expected:
exiftool -a -G1 -s -api QuickTimeUTC=1 -FileCreateDate -FileModifyDate -CreateDate -CreationDate movie.mp4
[MacOS] FileCreateDate : 2024:06:01 12:00:00+03:00
[System] FileModifyDate : 2024:06:01 12:00:00+03:00
[QuickTime] CreateDate : 1999:06:01 12:00:00+03:00
[Keys] CreationDate : 1999:06:01 12:00:00+03:00
exiftool -overwrite_original -api QuickTimeUTC=1 '-FileCreateDate<CreationDate' '-FileModifyDate<CreationDate' movie.mp4
Warning: Error 512 running "/usr/bin/setfile" to set FileCreateDate - movie.mp4
1 image files updated
exiftool -a -G1 -s -api QuickTimeUTC=1 -FileCreateDate -FileModifyDate -CreateDate -CreationDate movie.mp4
[MacOS] FileCreateDate : 1999:06:01 12:00:00+03:00
[System] FileModifyDate : 1999:06:01 12:00:00+03:00
[QuickTime] CreateDate : 1999:06:01 12:00:00+03:00
[Keys] CreationDate : 1999:06:01 12:00:00+03:00FileCreateDate seems to work with the following time zone related commands:
exiftool -overwrite_original -api QuickTimeUTC=1 -api TimeZone=America/New_York '-QuickTime:Time:All=2024:06:01 12:00:00' '-FileCreateDate=2024:06:01 12:00:00' '-FileModifyDate=2024:06:01 12:00:00' movie.mp4
1 image files updated
exiftool -a -G1 -s -api QuickTimeUTC=1 -api TimeZone=America/New_York -FileCreateDate -FileModifyDate -CreateDate -CreationDate movie.mp4
[MacOS] FileCreateDate : 2024:06:01 12:00:00-04:00
[System] FileModifyDate : 2024:06:01 12:00:00-04:00
[QuickTime] CreateDate : 2024:06:01 12:00:00-04:00
[Keys] CreationDate : 2024:06:01 12:00:00-04:00
exiftool -overwrite_original -api QuickTimeUTC=1 -api TimeZone=America/Los_Angeles '-QuickTime:Time:All=2024:06:01 12:00:00' '-FileCreateDate=2024:06:01 12:00:00' '-FileModifyDate=2024:06:01 12:00:00' movie.mp4
1 image files updated
exiftool -a -G1 -s -api QuickTimeUTC=1 -api TimeZone=America/Los_Angeles -FileCreateDate -FileModifyDate -CreateDate -CreationDate movie.mp4
[MacOS] FileCreateDate : 2024:06:01 12:00:00-07:00
[System] FileModifyDate : 2024:06:01 12:00:00-07:00
[QuickTime] CreateDate : 2024:06:01 12:00:00-07:00
[Keys] CreationDate : 2024:06:01 12:00:00-07:00- Matti
Thanks for the analysis, Matti
So Phil, I guess that the next ExifTool for Mac (whenever that is) should try getting/reading the local timezone of the user when using "SetFile" on any file, I guess?
Unless explicitly defined with e.g. -api TimeZone=Europe/Paris or like Matti's -api TimeZone=America/New_York ?
Great, thanks. All I need to do is remove the time zone before the call to setfile, and all should be good. I'm already converting to local time, which is what setfile expects. This will be fixed in 13.02.
- Phil
Thank you, Phil !
Please in the on-line manual or --help notes, do put a mention of this change for people needing to set a different timezone than their own computers (when needed) as I have never done this consciously outside the scope of adding e.g. +01:00 or +03:00 (which will now be discarded in a next ExifTool MacOS version) and I only discovered very recently this -api TimeZone=ΧΧΧ thing that other users mentioned (incl. QuickTimeUTC etc.)
Many thanks to you and everyone, I guess this closes the "error 512" talk from my side.
I'm not sure how to document this. It isn't specific to FileCreateDate since any date/time stored as UTC will behave this way. And the behaviour for FileCreateDate will be the same as it has been for MacOS pre-Sequoia.
- Phil
The change in setfile happened after Xcode 16.0. I wonder if Apple did this intentionally or if it reverts this in an update. Previously I have not paid much attention to the time zones in file dates because they behaved as expected anyway.
With the old Sonoma 14.6.1 and Command Line Tools for Xcode 15.3 setting FileCreatDate with time zone succeeds:
exiftool -a -G1 -s -FileCreateDate -FileModifyDate a.jpg
[MacOS] FileCreateDate : 1988:06:01 12:00:00+03:00
[System] FileModifyDate : 1988:06:01 12:00:00+03:00
exiftool -FileCreateDate='2001:06:01 12:00:00-07:00' -FileModifyDate='2001:06:01 12:00:00-07:00' a.jpg
1 image files updated
exiftool -a -G1 -s -FileCreateDate -FileModifyDate a.jpg
[MacOS] FileCreateDate : 2001:06:01 22:00:00+03:00
[System] FileModifyDate : 2001:06:01 22:00:00+03:00
After updating to Command Line Tools for Xcode 16.0 or 16.1 setting FileCreateDate fails:
exiftool -a -G1 -s -FileCreateDate -FileModifyDate a.jpg
[MacOS] FileCreateDate : 1988:06:01 12:00:00+03:00
[System] FileModifyDate : 1988:06:01 12:00:00+03:00
exiftool -FileCreateDate='2001:06:01 12:00:00-07:00' -FileModifyDate='2001:06:01 12:00:00-07:00' a.jpg
Warning: Error 512 running "/usr/bin/setfile" to set FileCreateDate - a.jpg
1 image files updated
exiftool -a -G1 -s -FileCreateDate -FileModifyDate a.jpg
[MacOS] FileCreateDate : 1988:06:01 12:00:00+03:00
[System] FileModifyDate : 2001:06:01 22:00:00+03:00
Without time zone in the command and with some manual calculations it succeeds the same was as in the old Xcode.
Local time 12:00 + computer +03:00 - -07:00 = 22:00 (1st June DST was ON in some parts of the world...):
exiftool -a -G1 -s -FileCreateDate -FileModifyDate a.jpg
[MacOS] FileCreateDate : 1988:06:01 12:00:00+03:00
[System] FileModifyDate : 1988:06:01 12:00:00+03:00
exiftool -FileCreateDate='2001:06:01 22:00:00' -FileModifyDate='2001:06:01 22:00:00' a.jpg
1 image files updated
exiftool -a -G1 -s -FileCreateDate -FileModifyDate a.jpg
[MacOS] FileCreateDate : 2001:06:01 22:00:00+03:00
[System] FileModifyDate : 2001:06:01 22:00:00+03:00
- Matti
"Nov. 5, 2024 - Version 13.02: Fixed problem setting FileCreateDate on MacOS Sequoia if the date/time contains a time zone"
Thanks, now commands using setfile work as usual also with Command Line Tools for Xcode 16.0 and later.
exiftool -a -G1 -s -FileCreateDate -FileModifyDate a.jpg
[MacOS] FileCreateDate : 1988:06:01 12:00:00+03:00
[System] FileModifyDate : 1988:06:01 12:00:00+03:00
exiftool -FileCreateDate='2001:06:01 12:00:00-07:00' -FileModifyDate='2001:06:01 12:00:00-07:00' a.jpg
1 image files updated
exiftool -a -G1 -s -FileCreateDate -FileModifyDate a.jpg
[MacOS] FileCreateDate : 2001:06:01 22:00:00+03:00
[System] FileModifyDate : 2001:06:01 22:00:00+03:00
exiftool -FileCreateDate='2001:06:01 12:00:00' -FileModifyDate='2001:06:01 12:00:00' a.jpg
1 image files updated
exiftool -a -G1 -s -FileCreateDate -FileModifyDate a.jpg
[MacOS] FileCreateDate : 2001:06:01 12:00:00+03:00
[System] FileModifyDate : 2001:06:01 12:00:00+03:00
- Matti
Hi Matti,
Thanks for the confirmation.
- Phil