I guess since exiftool is rather *nix oriented, this might seem a bit esoteric, but I stumbled upon it while using it on Windows.
The ntfs file system supports an infinite number of named "streams" ("forks" in other fs) that are moved around with the file and, other than separate files, don't clutter the scenery or can get easily separated. In Windows, they're accessed by separating the file name from the stream name with a ":". The streams are rather useful if you get used to the idea, for example for backing up the xmp data...
https://en.wikipedia.org/wiki/NTFS#Alternate_data_streams_.28ADS.29
https://en.wikipedia.org/wiki/Fork_(file_system)#Uses
... unfortunately, perl or(?) exiftool don't support streams like in ...
[C:\]exiftool -xmp -b image.jpg > image.jpg:xmp
[C:\]exiftool.exe -xmp:xmptoolkit image.jpg:xmp
File not found: image.jpg:xmp
... while of course the traditional way with a sidecar file works just fine ...
[C:\]exiftool -xmp -b image.jpg > image.jpg.xmp
[C:\]exiftool.exe -xmp:xmptoolkit image.jpg.xmp
XMP Toolkit : Image::ExifTool 10.29
Maybe you could have a look if perl or exiftool is at fault here that streams aren't recognized?
I googled NTFS file streams and found the following articles on the Microsoft developer site: aa364404 (https://msdn.microsoft.com/en-us/library/windows/desktop/aa364404(v=vs.85).aspx) and bb540537 (https://msdn.microsoft.com/en-us/library/windows/desktop/bb540537(v=vs.85).aspx).
I also found a reference to perl where it is stated that the standard perl file handling functions should normally be able to process file streams (see e.g. NTFS Streams in: Win32 Perl Programming: The Administrator's Handbook. Chapter 3 - Tools (http://www.codeproject.com/Articles/1002/Win-Perl-Programming-The-Administrator-s-Handboo)). If exiftool currently doesn't (fully) support streams, than perhaps it either doesn't use these standard functions (which is very well possible as those have problems, especially with e.g. Unicode in file names) or there is something else at play.
(Note: in your example, have you verified that image.jpg:xmp is indeed created by the output redirection?)
I just tried this on an NTFS filesystem and I can't access such a file using standard system commands:
C:\> echo test > a.jpg:test
C:\> type a.jpg:test
The filename, directory name, or volume label syntax is incorrect.
(the file a.jpg did exist, if this makes any difference)
- Phil
From the documentation on streams: type file:stream doesn't work. You need to use more < file:stream (hey, it's Microsoft; they always make things behave different than you'd expect ;))
:( If opening a file doesn't work with the standard Windows commands, then I don't see how one could expect it to work with ExifTool. Even if it did work with the standard Perl file i/o, as Hayo mentions ExifTool has to use different routines due to lack of support in the standard i/o library for filenames with special characters. So I don't think there is any hope of getting this to work with ExifTool.
- Phil
Edit: Having said this, if it works with Windows pipes, then you could bypass the problem by simply piping the file to ExifTool:
exiftool.exe -xmp:xmptoolkit - < image.jpg:xmp
Quote from: Hayo Baan on October 07, 2016, 08:56:10 AM
From the documentation on streams: type file:stream doesn't work. You need to use more < file:stream (hey, it's Microsoft; they always make things behave different than you'd expect ;))
In this case, that's simply lack of effort on MS' side with the outdated cmd.exe - for example in alternative shells like JPSoft's tcc, "type file:stream" works just fine. MS is good on delivering new technologies they only slowly adapt themselves - or never. A wild guess would be that powershell support for streams is better.
Quote from: Phil Harvey on October 07, 2016, 09:02:50 AM
Edit: Having said this, if it works with Windows pipes, then you could bypass the problem by simply piping the file to ExifTool
Thanks for discovering this, works for me - there doesn't seem to be any downside to the piping solution that I can think of right now.