u flag problem - RealWorld forums

I'm using PhotoResize400 to create reduced size copies of photos in my picture library in a new location. Using the -u parameter to resizing of only newly added files.

Command line is:
"N:\Pictures (for Xtreamer)\Resize\PhotoResize400.exe" -h1080 -n -m -u -r -e -c"n:\Pictures (for Xtreamer)\Photos\<PATH><NAME>.jpg"
"D:\_Data\Pictures\1 Photo Library\1 Library"

Problem is that some, but not all, existing files are always being resized. I've set up a test with just two source files. FileA - 1345Kb, 1299x1308 @ 1200 ppi; File B - 905Kb, 1293 x 1299 @ 1200Kb. On the first run the files are resized and sent to the new location ok, but each time I rerun the command FileA is processed again (although the resulting file characteristics are unchanged) and FileB is corretly skipped.

With a photo librabry of over 6000 files this causes quite a problem.

Using XPsp2 on an Intel P4, 2400Mhz machine.

Any ideas?

David

Re above, the command is all on one line, despite it not appearing so in the post.
David

It is hard to say why it works for one file and not for the other. The first thing I would do it to check the timestamps on the problematic file - could it be that it has an invalid time stamp - like from the future, possibly from a wrongly configured camera?

Timestamps for both files (as reported via properties box under Windows Explorer) have the same created, modified and accessed dates, times are a few seconds different, none are in the future. The read only and archive attributes are set on both files.

These particular .jpg files are both scanned images and have no exif data within them (checked using photo editor).

Could you send me the file to info@rw-designer.com? I'd like to test it myself.

Vlasta - email on it's way, many thanks. David

Just done a few more tests, and found that if I change the destination folder for the resized files from the NAS drive (N:) to somewhere on my local drive (D:) then the test works ok, with subesquent runs of the resize command correctly detecting that the file already exists.

So the problem is possibly something to do with a slightly longer delay in accessing the NAS drive when checking for the existance of the file, although why it consistently fails on one file but not the other escapes me for the moment.