Piping filedata into exiftool when daemonized

[jteb]

Hi,

I'm trying to change some of our code to make use of the -stay_open feature. (stay_open rocks, I've been silently hoping for a feature like this since I first started using exiftool).

Because of problems with opening files with a unicode pathname on Windows, I resorted to using pipes to feed file data into exiftool when running on Windows. I'd like to do the same while having a pipe open to an exiftool instance that's running in -stay_open mode.

I'm running exiftool from Java as

Code Select Expand

exiftool -stay_open "true" -@ - and I keep a reference to the input pipe. Then I write some commands to the pipe:

Code Select Expand


-n
-m
-s
-
-execute


I was hoping to stream my file data into the pipe at this stage, but I get an error 'Unknown file type'. Perhaps I'm being plain stupid here, but I have a feeling this make actually work with some modifications. When going through the exiftool code, I end up in the RandomAccess, where I believe not all the data is read from the pipe or perhaps it's being read wrong. However, I do think that the data read is actually coming from the pipe (at least it looks like it opens the stdin file pointer). My Perl knowledge just stops about here though, so I don't have a clear idea of how to debug this. Or whether this is at all possible?

Is this something that may even be accomplished? Any pointers in the right direction would be very useful.

Cheers,
Jan

[Phil Harvey]

Hi Jan,

Unfortunately you only have one stdin filehandle to work with, and it is either used for input data files (-), or for input command arguments (-@ -), but not both.  I can't see any way to do what you want without using a temporary file for either the image, or the command-line arguments.

If there were two input filehandles (like there are with output filehandles stdout and stderr), then this could work. But sadly this isn't the case.

However, there are ways that this could be done (using shared memory or TCP sockets for example), but building an advanced capability like this into the command-line application doesn't make much sense, especially since you can always write your own application using the ExifTool API to do whatever you want (although I admit this probably isn't a very appealing solution unless you are a Perl programmer).

- Phil

[jteb]

Thank you very much Phil.

I think I'll try using an argument file and use my pipe for the image. If that fails, perhaps I'll pick up Perl

Cheers,
Jan

[Christian Etter]

Hello Jan,
Have you succeeded piping in multiple images? I am just trying to use -stay_open together with writing multiple files to stdin (due to non-ansi file names which exiftool cannot read), but get the same error message. Here is what I do (using .net):

• Create an empty arg file
• 
  Programmatically start exiftool using the following parameters:
  exiftool -stay_open True -@ "c:\ExistingEmptyArgFile.tmp"
  
• 
  Open the arg file, append the following text, then close the arg file:
  "-EXIF:ModifyDate\n-EXIF:DateTimeOriginal\n-EXIF:CreateDate\n-SYSTEM:FileModifyDate\n-\n-execute\n"
  
• 
  Write the entire jpg (binary) to the standard input, then flushing stream to prevent buffering.
  Since I cannot close the stdin to signal the end of the file, I expect exiftool to assume end of file when the arg file is updated.
  
• 
  Repeat steps 3 and 4 for each file.
  stderr outputs "Error: Unknown file type - -" and stdout reports "{ready}" for every call.
  Reversing Step 3 and 4 will not work (it hangs when writing data to stdin).
  
• 
  Finally append "-stay_open\nFalse\n-execute\n" to arg file.
  
• 
  Close the input stream.
  

Phil: From your previous comment I assume that it is legal to use "-" within an arg file, as long as the arg file itself is not written to stdin itself. Am I missing something here?

Thanks

Christian

_____________________________
exiftool 8.65 on Windows 7 x64

[Phil Harvey]

Hi Christian,

Using "-" in an argfile should work.  If I get a chance I'll run some tests myself to see if I can figure this out.

- Phil

[Phil Harvey]

Hi Christian,

I failed in my first attempt to get this to work.  When I pipe a file to exiftool, it reads the first file but doesn't receive and end-of-file (and start processing) until I close the pipe.  But then I am stuck because I can't send the next file to exiftool.

There are other ways around the file name problem though...  What about creating a soft link to the file, then passing the name of the soft link to exiftool?  Like this:

mklink link.jpg "c:\a\directory\file name with funny characters.jpg"

- Phil

[Christian Etter]

Hi Phil,

thanks for the quick feedback. Probably the only way to make piping multiple files work, would be if exiftool could assume an EOF of the current file as soon as the next instructions are written to the arg file. I am not sure about Perl, but in some programming languages this might require the use of async IO.

Creating hard links to the files and then cleaning up afterwards will definitely work on Windows as long as the user is able to write somewhere on the same partition (i.e. drive letter) as the original image. Creating links in the system temp folder will therefore not work if the user has more than one partition in the system. Cross partition links could be created based on soft links but I could not get soft links to work with exiftool on Windows (since exiftool will list the content of the link file instead).
A similar solution is the workaround using DOS 8.3 file and directory aliases (together with the overwrite in place option when editing), the shortcoming would be that the support of 8.3 file names has become optional since Windows 2000 and can not be relied on.

Looking forward to some positive news some day on this thread: https://exiftool.org/forum/index.php/topic,3155

Christian

[Phil Harvey]

Hi Phil,
Looking forward to some positive news some day on this thread: https://exiftool.org/forum/index.php/topic,3155

Right.  I must admit I haven't been very motivated when it comes to patching Windows deficiencies.  One main reason I wrote ExifTool in Perl instead of C++ was to avoid platform dependencies.  Oh well.

_ phil