iMatch 2023.9.2 cannot delete file

[Carlo Didier]

iMatch refuses to delete files with the attached error message.

The files are neither read-only in iMatch nor in the NTFS file system. My user account has "full control".
No other application has any files open (photo folders are excluded from the antivirus).
Database is not read-only either.
Restarting iMatch or Windows doesn't help.

I can delete the same files in Windows file explorer without any issues.

What else can be blocking?

[Jingo]

Not sure if it will be helpful since most likely it is IMatch that is doing something with the file - but if you use the windows Resource Monitor and search the Handles for that exact filename, it will tell you what PID/program is locking that file.

[Carlo Didier]

I already checked that. No other application has the file open. And I can delete it from Windows Explorer. It is not locked.
There are quite a number of files I can't delete from iMatch.

[Carlo Didier]

Note that I can rename the file in iMatch. But not delete.

[Carlo Didier]

I have now (still in iMatch) copied the file to another folder and I can't delete it there either ...

[Mario]

This error message comes from straight Windows.  The system function IMatch calls to delete the file failed.
More details may be in the log file.

Reboot your PC then retry.

[Carlo Didier]

This error message comes from straight Windows.  The system function IMatch calls to delete the file failed.
More details may be in the log file.

Reboot your PC then retry.

I had attached the log file to my first post.

[Carlo Didier]

After a third reboot, I could finally delete the files.
I think it was iMatch itself that somehow blocked them (apart from my web browser and Outlook, nothing else was running).
Recently, iMatch often gave me a warning on starting that it hadn't shutdown correctly and it looks like, even when I have closed iMatch and it isn't visible anymore in task manager, somehow it is still running, because when I don't wait at least another 3-5 minutes, when I try to start iMatch again, it says there is still an instance running.
Maybe those issues are related.
Note that the database diagnostics shows no errors.

[Mario]

Check your virus checker. It may play games with IMatch. Add an exclusion for IMatch and see if the effects are gong away.

[Carlo Didier]

Check your virus checker. It may play games with IMatch. Add an exclusion for IMatch and see if the effects are gong away.

See my starting post. iMatch database and photo folders are excluded. And I checked if any other application had the files open.
I can rename in iMatch, but not delete.
I can delete in Windows file explorer, so permissions are ok and file not locked.

[Mario]

iMatch often gave me a warning on starting that it hadn't shutdown correctly and it looks like, even when I have closed iMatch and it isn't visible anymore in task manager, somehow it is still running,

Typical sign of a virus checker badly interfering with IMatch.

in, it says there is still an instance running.

Maybe wait for a bit? I don't know the database size (managed assents) or how many processor cores your PCs has, but sometimes IMatch may take a few seconds to shut-down - especially when it is in full flight processing files.

IMatch does not lock files for more than a few ms. There is no need.
When it opens files itself (while calculating a checksum during ingest), it opens the file in "share read" mode. It does not allow other processes to write to the file (or delete it) when it tries to calculate the checksum, but there is no problem with other processes reading the file. So, no lock. Deleting a file currently read by IMatch will fail, though. But the typical runtime for calculating a checksum for a RAW file or similar is maybe 50ms to a few seconds for large videos files. RAW files typically take 0.2 seconds. Then IMatch closes the file again.

If IMatch it processes a file via WIC, LibRaw, FFMPeg (video files) or, likely, Windows shell thumbnail handlers for formats not supported by IMatch directly, the threads processing the files may "hang" for extended periods of time until WIC, LibRaw, FFMPPeg or the shell thumbnail handler returns. And that times the number of processors your system has.
And if the virus checker interf4eres an and blocks ExifTool, WIC or whatever, things will be nasty. IMatch can do nothing about either cause.

WIC is always a candidate for locks if it chokes on a RAW file and just stops. Windows will not "release" WIC codecs crashed that way until you close IMatch or Windows decides to terminate IMatch because of multiple instances of WIC codecs all crashing on unsupported image files.

There are known incidents where a WIC codec or even LibRaw chokes on a badly damaged or unsupported file for an extended period of time. This will be logged by IMatch.

ExifTool may choke on a damaged or really badly unsupported file for 120 seconds until IMatch terminates ExifTool.
Again, if this happens on multiple threads because of a bunch of damaged or unsupported image files, wait time may increase until IMatch gets a chance to clean things up. But that's really rare. and always leaves warnings in the log file.

In my experience, if such things happen, the virus checker is the problem or there are many, many files which are corrupted or "unsupported" in a way that breaks WIC, LibRaw, FFMPeg or the shell thumbnail handlers in Windows.
All effects should leave traces in the IMatch log file.

[Carlo Didier]

I can exclude the virus checker as all exceptions are set as needed and the files were only un-deletable within iMatch. Any other application, even if iMatch was still running, could delete the files. iMatch could only rename them. It was only iMatch that had the problem.

Letting iMatch "idle", i.e. doing nothing within iMatch for a long time (~1 hour), so that all background processing could finish, did not solve the problem either. Neither did restarting iMatch. Something within iMatch had an issue. But apparently the log (in debug mode) did not seem to give any useful information about it.

I cannot reproduce it now anymore, but if it happens again, I will inform you and not restart anything, so we may be able to do more analyzing.

[Mario]

It was only iMatch that had the problem.

 IMatch uses services provided by Windows to copy, move, rename and delete files.
If Windows returns an error, it is logged and the user sees a warning.

In your case, Windows told IMatch that it cannot delete the file, and that's all I know. There are no further diagnostics available for these Windows features. IMatch logs the error message as returned by Windows.

[Carlo Didier]

Hmm, then I might get more info in such a case from running a tool like filemon from sysinternals. Should have thought of that earlier, but as the issue only occured within iMatch, I completely missed that option.