The below exiftool cmd when run directly on cmd prompt is working fine:
exiftool.exe \\HOSTNAME\workarea\import\36\content\test.DNG -preview:all -b -m -W \\HOSTNAME\workarea\import\36\content\4%f_%t.%s
Also if we run the same command via java process: Runtime.getRuntime().exec(command); it is working fine.
But when the same command is executed via java process Runtime.getRuntime().exec(command, null, workingDir); it is failing. Here the value of workingDir = \\HOSTNAME\workarea\import\36\content
This is happening only when the file is on network location, because when the working directory is
C:\data\workarea\import\36\content the exiftool cmd with java process Runtime.getRuntime().exec(command, null, workingDir); works fine.
Below is the log statement for the failed cmd:
execCommand: Process started.
execCommand: STDOUT:
1 image files read
3 files could not be read
0 output files created
execCommand: STDERR:
Error creating directory /
Error creating //HOSTNAME/workarea/import/36/content/4/test_JpgFromRaw.jpg
Error creating directory /
Error creating //HOSTNAME/workarea/import/36/content/4/test_PreviewImage.jpg
Error creating directory /
Error creating //HOSTNAME/workarea/import/36/content/4/test_ThumbnailTIFF.tiff
execCommand: Process completed with exit value 1
exiftool version:12.29
I don't see how this could be an ExifTool issue, but for some reason it seems that ExifTool doesn't think that "/" is a directory when run like this. Why should this be different than when run basically all other ways?
Just for fun I will add a patch so ExifTool doesn't test to see if "/" is a directory, but I don't know if this will help.
- Phil
I dont know what Runtime.getRuntime().exec(command, null, workingDir);
does. But if it starts a new cmd.exe that will fail, because cmd.exe does not support UNC paths.
Microsoft Windows [Version 10.0.22631.4037]
(c) Microsoft Corporation. All rights reserved.
P:\>c:
C:\>cd \temp
C:\temp>cd \\10.10.10.12\backup
'\\10.10.10.12\backup'
CMD does not support UNC paths as current directories.
C:\temp>
I had another thought. If the Perl runtime environment doesn't properly identify the system it could cause a problem like this. You can use this command to see the system type in the ExifTool environment:
exiftool -p "${filename;$_=$^O}" FILE
- Phil
Just ran a test with ExifToolGui, that has a similar function builtin. It runs OK, so I dont think ExifTool/Perl is a suspect.
This is the function in GUI:
extract1.jpg
Extracts are on the network path:
extract2.jpg
Sysinternals process explorer showing how Exiftool.exe is called:
sysinternals.jpg
If it helps, this is the (Delphi/Pasal) source:
https://github.com/FrankBijnen/ExifToolGui/blob/main/Source/ExifTool.pas (https://github.com/FrankBijnen/ExifToolGui/blob/main/Source/ExifTool.pas)
Look for method function ET_StayOpen(WorkDir: string): boolean;
Quote from: Phil Harvey on August 21, 2024, 09:05:55 AMexiftool -p "${filename;$_=$^O}" FILE
I my case, that works, it returns MSWin32.