Drag and Drop move of folder failed - files in folder are gone! And two odditis

[ubacher]

1. I tried to move a folder up under another one using drag and drop.
This failed, The folder remained where it was but the (fortunately only) two files in it are lost!

Line in the log: 10.03 16:55:36+60016
shows error 32.

2. While looking at the log file I noticed it tries to create cache files for .gpx files. I assume it should not try to cache these.

3. While looking at the log file I noticed  that it loads files twice in a row. Odd?
Look at log file line starting with:10.03 16:39:16+  266  for an example

4. I have some .jxl files which I collected for experimental work. Imatch reports warnings that it can not load these.
This is legit - I should probably keep these files outside of Imatch.

imatch_log20241003.zip 

[Mario]

2. While looking at the log file I noticed it tries to create cache files for .gpx files. I assume it should not try to cache these.

IMatch by default does not index GPX files. I assume you have added these as a user-defined format? Which class did you use?

Windows has returned error 32 ( ERROR_SHARING_VIOLATION ) for some reason when moving the file.
IMatch does not move the files itself. It uses Windows shell functions for move and copy operations and these usually either work or fail. Search for the file names if you can remember to figure out where Windows has moved the files, if at all.
Make sure the files are not open in another application or process when you move them.
If these were JPG files and the Quick View Panel was open, Windows WIC may have locked the file (this sometimes happens for reasons unknown).

While looking at the log file I noticed  that it loads files twice in a row. Odd?

It does not load the file twice, it just logs different levels in the stack trace.

4. I have some .jxl files which I collected for experimental work. Imatch reports warnings that it can not load these.
This is legit - I should probably keep these files outside of Imatch.

Again, user-defined file format. IMatch has no further knowledge about these files and will try to load them. Which fails and that's OK.

[ubacher]

gpx files: I added these under "auxilliary". What should they be?

.jxl files: I don't recall having added them, I might have. They are under "image". Interesting is that some .jxl files are read
ok. The files I have are for demonstrating the different possibilities of encoding using jpx. And these "unusually" coded
files can not yet be handled by (?Windows). (Note: Irfanview can show all these files.)

As for the failed move of a folder: I looked hard for the two missing files. (a dng and a jpg) I could not find them.
I think that is the first time that Imatch lost some files - at least for me. It is for that reason I thought it might be
of especial interest to you, Mario. It is possible that PS somehow still locked these files - but is was many hours
previously that I worked on the dng. But a locked file could maybe not be moved but it should not disappear - no?

[Mario]

Try text files, since GPX files are text files.

JXL and JPX are rarely used formats. I don't even have any in my collection. Should I? Which applications produce these formats?

Adobe uses the JPXL (I assume that's the same?) in some newer DNG files, causing both Windows WIC and LibRaw to fail to load the files. The only way to handle these files in DNG was for me to pull in the full Adobe DNG SDK with tons of dependencies and virtually zero documentation from Adobe and "marry" it with LibRaw.

Not sure if we all need new file formats. HEIC/HEIF (patent nightmare), JPEG2000 (short-livend), WEBP (mostly dead) and now JPGXL. And of course many, many variants of DNG formats.

I cannot tell how the files were lost. You moved a folder. IMatch told Windows to move folder A to B. While Windows is doing that, IMatch receives notifications which allows it to to keep the database in sync. When Windows is complete, IMatch gets a result. In your case this was error 32, "sharing violation". Which usually does not harm, since if a file is locked in another application, Windows cannot move it. Not sure what Windows did in this case.

IMatch leaves this to Windows, since "move a file" has become really complicated over the years, considering off-line storage, link points and whatnot. No need for IMatch to try to invent it's own move/copy routines, Windows usually is quite good at it.