"file not found" on -@ execution

[calberga]

Back again!

I'm trying to set keywords from a args-file, and exiftool isn't finding some of my files, although they are there.   Note that the majority of the sequences worked as advertized.

The command given was:

exiftool FILE > D:/nametrace.txt -@ D:/nametags.args -common_args -L -sep " : " -P -overwrite_original

Here are a few of the error messages:

Code Select Expand

Error: File not found - D:/Photographs/Boxed Slides/1957-Summer 1960/028 20 (black Num).jpg
Error: File not found - D:/Photographs/Boxed Slides/1957-Summer 1960/027 19 (black Num).jpg
Error: File not found - D:/Photographs/Boxed Slides/1957-Summer 1960/004 18 (light #).jpg
Error: File not found - D:/Photographs/Boxed Slides/1957-Summer 1960/008 19 (light #).jpg
Error: File not found - D:/Photographs/Boxed Slides/1957-Summer 1960/010 21 (light #).jpg
Error: File not found - D:/Photographs/Boxed Slides/1957-Summer 1960/011 -- (large square) (Madison,
unknown date).jpg
Error: File not found - D:/Photographs/Boxed Slides/1957-Summer 1960/006  3 (black #).jpg
Error: File not found - D:/Photographs/Boxed Slides/1957-Summer 1960/007 -- (covered #).jpg
Error: File not found - D:/Photographs/Boxed Slides/1957-Summer 1960/005 15 (black #).jpg

Resulting from the following snip from the args-file

-keywords=Woods, Elizabeth : Woods, Ann Helen
D:\Photographs\Boxed Slides\1957-Summer 1960\028 20 (black Num).jpg
-execute
-keywords=Woods, John
D:\Photographs\Boxed Slides\1957-Summer 1960\027 19 (black Num).jpg
-execute
-keywords=Moruko, Mamie : Snider, Marcia : Canham, Donald : Snider, Robert
D:\Photographs\Boxed Slides\1957-Summer 1960\004 18 (light #).jpg
-execute
-keywords=Alberga, Cyril N.
D:\Photographs\Boxed Slides\1957-Summer 1960\008 19 (light #).jpg
-execute
-keywords=Alberga, Cyril N. : Baron, Sandra B.
D:\Photographs\Boxed Slides\1957-Summer 1960\010 21 (light #).jpg
-execute
-keywords=Snider, Marcia : Dodds-Belanger, Margaret
D:\Photographs\Boxed Slides\1957-Summer 1960\011 -- (large square) (Madison, unknown date).jpg
-execute
-keywords=Snider, Robert
D:\Photographs\Boxed Slides\1957-Summer 1960\006  3 (black #).jpg
-execute
-keywords=Snider, Marcia : Snider, Robert
D:\Photographs\Boxed Slides\1957-Summer 1960\007 -- (covered #).jpg
-execute
-keywords=Snider, Marcia : Snider, Robert
D:\Photographs\Boxed Slides\1957-Summer 1960\005 15 (black #).jpg
-execute

Can anyone identify the problem here?

[Phil Harvey]

I can't see anything wrong with these file names.  There are certainly problems with file names containing accented characters on Windows, but this isn't the problem here.

Is there anything you can see that is common to the file names that cause problems?  Brackets perhaps?  Spaces? ...

- Phil

[calberga]

There are several things that occur in one or another of the names, but not in all.

1) very long path+file names
2) #, [, ]
3) some accented characters such as é, Î, ü,
4) double spaces, double hyphens
5) ½
perhaps others.  I tried redirecting the console output to a file, but the error messages ignored that, so I had to grab some as they went by.  I haven't used the console interface for a  long time, and then on IBM 3270 attached to CP/CMS or VM machines.  A different world.  What am I missing to get all the error messages into a file?  All I get is:

Code Select Expand

   1 image files updated
    1 image files updated
    0 image files updated
    1 files weren't updated due to errors
    1 image files updated
    1 image files updated
    0 image files updated
    1 files weren't updated due to errors
    0 image files updated
    1 files weren't updated due to errors
    1 image files updated
    0 image files updated
    1 files weren't updated due to errors
    1 image files updated
    1 image files updated

This from a bad spot, there are hundreds or thousands of good updates in a row in places.

I'm recovering my programming after 20 years of retirement, and using the only non-assembler language that I had  much experience with, LISP.  Still haven't tried reading and writing tags directly, but that may be what I have to do.  I am generating the args-files from Picasa files with some LISP programs, which helps.  Unfortunately (for me) everyone seems to attach this via "php", which I know NOTHING of!

[Phil Harvey]

I'm not sure how to redirect stderr to a file in a Windows cmd shell, but if it is like a Bourne shell, you would do it with:

SOME_COMMAND  2>&1  > out.txt

But I certainly expect the file names which contain non-ASCII characters (é, Î, ü, ½, etc) to fail when you try to access them with ExifTool.  (This is a known problem.)

- Phil

[calberga]

Actually, the only one that I know failed is the ½,  The é works, and I actually don't have any examples of other accented characters.  I'm going to mull this over, and try and capture the error stream, but it may not be for a few days.  I could do a massive rename, but that would through Picasa into a tizzy, the poor dear.  It really is a user-hostile program, but  it is the simplest I've found to capture the identities of people in the pictures, it just doesn't tag the images with the names!

Maybe I can cobble together a rename, build argslist with new names, run exiftool, and name back.  Messy, but conceivable. 

[Phil Harvey]

On more thought:  Check to be sure there are no non-ASCII spaces and dashes in the file names.  There are Unicode non-breaking-space and non-breaking-dash characters which look just like their ASCII counterparts in most fonts.  Although this is a long shot because I don't know of any mechanism whereby you could get these into a file name by accident.

You are right that some accented characters work on some systems, but I think it may depend on your Windows settings.  So if you changed system code pages, this behaviour may change.

- Phil

[calberga]

Thanks for the suggestion, I'll check it.  The text is all being filtered through the LISP programs, which are somewhat idiosyncratic with regard to character sets, and through Picasa as well.  I have to experiment with setting the code page on the DOS-box (i.e., Command Window).  There shouldn't be any Unicode characters in the mix.  I use an old program, EditPad, which doesn't know from Unicode, so stuff would show up as digraphs when I look at it.  I do have my keyboard set to "US International" which gives me all (or most) of the Latin1 code page, and I do use it for diacriticals and some special characters, such as € ¼ ½ ¾ § ß etc. (I don't know how those will look to you, to me they are Euro sign, 1/4, 1/2, 3/4, section mark, German sharp s or beta.  Since I see them as such in EditPad I know they are single characters.  Also, the version of LISP I'm using, and the functions are input/output symmetric (although the console display isn't) so that should be okay.

Weird.  I could attach an example or two, but I don't know if the attachment machinery is safe from changes between systems.  Here is a single filename, from the argument list, which failed.  Perhaps you can see something in the original.

[Phil Harvey]

I just tried your argument file.  I had to change I: to C: for my system, but it worked just fine after I created the appropriate .jpg file. (tested on WP SP3)

- Phil

[calberga]

I guess I need to find a brick wall to beat my head against!  I'm off to look for tagging code in LISP.  That or filename changing.  Many thanks.

[calberga]

I have dug a little deeper, and I wonder if there is a timing problem.  Note that the files I am working on are stored on a USB connected 1 TB hard drive, which might slow the access times.

I found that running a set of args where:

Code Select Expand

-keywords=...

with:

Code Select Expand

-comment=...

on eight of the files which failed now works.

Could it be that the setting of keywords takes more time (particularly when there are multiple entries delimited by a non-standard separator (" : " in my case)) than the setting of the non-list tag, comment?  And if this is so, could that result in an erroneous "file not found" return from some part of the process?

Just wondering.

[Phil Harvey]

If you get errors writing a file it could be interference with anti-virus software.  These types of interferences are timing dependent.

- Phil