Getting list of successful copy actions following an Error

[Skids]

I have a working exiftool command that is being called from an Applescript.

Code Select Expand

exiftool  -v -m  -r  '-FileName<CreateDate'  -d  '/Volumes/Images_Disc_02_Master/Ingest Testing 2/%Y/%Y-%m/%Y-%m-%d_%H%M%S_%%f.%%e' -o dummy/ '/Volumes/OM SYSTEM/DCIM copy/'
The command above copies and renames source files placing them in a new directory structure.  The command string is stored in a variable 'cmd' and is executed using this line of Applescript

Code Select Expand

set tResult to do shell script (cmd)
The rest of the Applescript relies on having a list of new filepaths and this is being extracted from the verbose log file that gets stored in variable tResult once exiftool completes without error.

The issue is that when exiftool throws an error nothing gets written back to tResult meaning that the details of any successful file copies are lost to the Applescript application.  The most common source of error occurs when a source file already exists in the destination directory.

It appears that exiftool processes all the files in the source folder, copying those that have no duplicates in the destination into the destination and then it throws the error with an error message that lists the files that it has been unable to copy.

Is there any way of getting a list of files that have been copied even when an error occurs ?

[Phil Harvey]

It sounds like the -efile option may give you the list of files that you want.

- Phil

[Skids]

Unfortunately -efile writes a list of file names the that have failed to be copied whereas I am trying to get the names of files that have been copied without error.

What is frustrating is that when run from terminal exiftool reports both successful copies and files that caused an error in the one report.  Unfortunately when an error gets raised it prevents Applescript from receiving the log file.  I guess the error could be being raised by exiftool or the shell.

However, I found this command on the web

Code Select Expand

2> /dev/null apparently it redirect the stderr to null.  This does not prevent an error being raised but the error message no longer contains errors but does contain a list of file copy actions.
Error message raised without the command :

Code Select Expand

Error: '/Volumes/Images_Disc_02_Master/Ingest Testing 2/2025/2025-02/2025-02-06_102855_GX003910.DNG' already exists - /Volumes/Images_Disc_02_Master/Test SDCard/GX003910.DNG
Error: '/Volumes/Images_Disc_02_Master/Ingest Testing 2/2025/2025-02/2025-02-06_102920_GX003911.DNG' already exists - /Volumes/Images_Disc_02_Master/Test SDCard/GX003911.DNG
Error: '/Volumes/Images_Disc_02_Master/Ingest Testing 2/2025/2025-02/2025-02-14_135505_OM540001.JPG' already exists - /Volumes/Images_Disc_02_Master/Test SDCard/OM540001.JPG
Error: '/Volumes/Images_Disc_02_Master/Ingest Testing 2/2025/2025-02/2025-02-14_135505_OM540001.XMP' already exists - /Volumes/Images_Disc_02_Master/Test SDCard/OM540001.XMP

Error message when using the command:

Code Select Expand

======== /Volumes/Images_Disc_02_Master/Test SDCard/GX003908.JPG
Setting new values from /Volumes/Images_Disc_02_Master/Test SDCard/GX003908.JPG
'/Volumes/Images_Disc_02_Master/Test SDCard/GX003908.JPG' --> '/Volumes/Images_Disc_02_Master/Ingest Testing 2/2025/2025-02/2025-02-04_130339_GX003908.JPG'
Rewriting /Volumes/Images_Disc_02_Master/Test SDCard/GX003908.JPG...
Nothing changed in /Volumes/Images_Disc_02_Master/Test SDCard/GX003908.JPG
======== /Volumes/Images_Disc_02_Master/Test SDCard/GX003910.DNG
Setting new values from /Volumes/Images_Disc_02_Master/Test SDCard/GX003910.DNG
I can use this list, as the third line is what I am trying to capture, but is this extra shell command safe or advisable to use?

[Skids]

I found the following question and answer published by Apple in this tech note

Question:

When I run my command in Terminal, I get a bunch of output, but when using do shell script, some of it is missing.

Answer:

When running in Terminal, standard output and standard error are both sent to the same place, so it is difficult to tell them apart. do shell script, on the other hand, keeps the two streams separate. If you want to combine them, follow the command with 2>&1 like this:

Code Select Expand

do shell script "command 2>&1"

See the sh man page under "Redirection" for more details.

Using "2>&1" at the end of my exiftool command string means that when an error is thrown the error message returned contains both the errors and the successful actions which are normally returned when no errors occur. 

The error is thrown because exiftool returns a non zero status value to indicate that something went wrong and Applescript acts on this and fails to read the standard output.

[Phil Harvey]

Unfortunately -efile writes a list of file names the that have failed to be copied whereas I am trying to get the names of files that have been copied without error.

I don't think you read the -efile documentation.

- Phil

[Skids]

-efile[NUM][!] TXTFILE           Save names of files with errors

? !

[Skids]

Unable to read what I'm unable to find.

Simple searches for exiftool -efile or exiftool efile fail to find the documentation.  Next I worked through many although not all the page links from the front page and searched for efile and found nothing. 

In the end reason I found it was by searching on this forum where I found links to the command.  I now know that a web search for the full command as listed in shell man does find the page, so thats the way to go in the future.

-efile[NUM][!] TXTFILE
Save the names of files giving errors (NUM missing or 1), files that were unchanged (NUM is 2), files that fail the -if condition (NUM is 4), files that were updated (NUM is , files that were created (NUM is 16), or any combination thereof by summing NUM (eg. -efile3 is the same has having both -efile and -efile2 options with the same TXTFILE). By default, file names are appended to any existing TXTFILE, but TXTFILE is overwritten if an exclamation point is added to the option (eg. -efile!). Saves the name of the file specified by the -srcfile option if applicable.

I can see that -efile8 or possibly 16 lists the files I'm interested in but it requires going via a file which on MacOS has the potential to cause issues and is a little clumsy. 

Merging the standard output with the error output seems to work o.k. unless you are hinting that its a bad idea.

[Phil Harvey]

The stdout+stderr technique should work.

It is good to be aware of the "Option Details" section of the application documentation.

- Phil