What are those temp files?

[Gerhard]

hello,
what are those temp files, which are generated during import?
they are created inside user\appdata\temp and have all 0KB.

[Mario]

I don't think these files are created by IMatch. IMatch uses "imt" as part of temporary file names.
For video processing (generating thumbnails from keyframes) IMatch uses numerical file names.
I cannot find any reference to "pli" in the IMatch source codes.

Which file types were you indexing?

[Gerhard]

I import mainly jpg and png.

processmon shows IMatch as source.

It looks like those are generated in the import phases before and after "Importing Metadata".
imt temp files are generated and deleted while the "Importing Metadata" phase is active and they relate to exiftool.

[Gerhard]

I don't want to hijack this thread, but I want to at least explain, why I asked this question:
It seems that those temp files are generated, but not deleted. As the naming includes only 4 hexadecimal values, the maximum number of temp files is 16^4 ~65000. Means as soon as those are used, IMatch starts to take 5 min per file import...

[Mario]

I have no idea where these files come from.

IMatch uses the extension .tmp in very few places. IMWS uses it with a file name generated from a UUID (long number) once to test if it can create a file in TEMP during startup. But the GUID is much longer than the number we see in your screen shot.

Some file format plug-in use it, but with the imt_ file name prefix.

IMatch uses imt_ when creating temporary files while extracting metadata, but with the .xmp file extension.

There is no format string containing "pli, \pli or pli% in the entire IMatch code base.
When creating temp files, IMatch uses imt_ to make it easy for me to identify if temp files are not deleted.

I have no pli files in my TEMP folder.
When I start IMatch and index a couple of folders with JPG, RAW, PNG and other files, no pli files are generated.
Viewing files, writing back etc. does not create a any pli files.

We have discussed this a while ago in this thread:  https://www.photools.com/community/index.php?topic=10727.0

I see the MsMpEng.exe executable accessing the files (Microsoft Malware Protection / Windows Defender) in your screen shot.
That was also discovered in the old thread, but without results.

Also, it seems to be always the same file name in your screen shot. Several calls to CreateFile (which is also logged when an application opens a file).

[Mario]

Do you mean when you import a single JPG file (or do a Shift+Ctrl+F5 > Force Update), a pli file is generated?
And why does IMatch slow down to 5 minutes? Maybe somehing waits for a "free" pli file name? But then IMatch would surely log many warnings to the log file. Can you attach the log file of this 5 minute problem session? See log file

[Gerhard]

I will exclude the folder from defender and test again.
Nevertheless, the 5 min issue is documented in here https://www.photools.com/community/index.php/topic,14921.0.html
It seems not the MS update was the issue, but the update did clear the temp cache. Server and VM never run Imatch before and import 1300 files is far below the 65k tmp file issue.

[Gerhard]

it seems that .png files trigger this. jpg don't seem to create those tmp files.
With exclusion of defender active, see screenshots, still creating those files.

[Mario]

Nevertheless, the 5 min issue is documented in here https://www.photools.com/community/index.php/topic,14921.0.html

Don't expect me to make this kind of mental jumps. I process so many emails and community posts every day, I cannot possible remember all of this from a "5 Minutes" comment.

PNG files are processed by the 3rd party image component IMatch uses. No external dependencies. Same as JPG files.


I've forcefully rescanned a folder with 900 PNG files already in the database.
No pli files in temp.

I've added 100 PNG new files from various applications to my test database.
No pli files in temp.

Did the usual stuff, metadata editing, AutoTagger, write-back, deleting PNG files.
No pli files in temp.

In the original thread I've linked to, several users checked for pli files in their temp folders, without success.

So what is the difference between your PC and PNG files, and other PCs and PNG files?
Are the files really 0 bytes in size?
Anything special you do? Where come the PNG files from? Do you use Metadata Templates during indexing? Versions? Automatic write-back? Which features and options do you use? Does the number of pli files match the number of PNG files you add to your database?

I would assume that I can find the pli prefix in the IMatch code base, but I cannot.

[mopperle]

I just made a small test:
- deleted all pli*.tmp files
- started IMatch and then doing nothing
- these files haven been created:

The normal  IMatch logfile is ok, IMHO interesting might be the IMATCH6_CEFLOG.TXT file

On the web I do not find any reference to pli*.tmp files. Maybe something from exif tools or the AI things?

[mopperle]

And just to make sure: the path in Gerhards first post is not correct, it should be "C:\Users\USERNAME\AppData\Local\Temp"

[Gerhard]

I'm always astonished how fast you reply and how helpful you are or try to be. So first of all: thank you.

I'm looking only at the import. I have auto indexing and metadata writeback disabled.
Not every png file creates a tmp file.

the files are empty in notepad and show in properties 0 bytes.
I don't apply any templates.
Basically installing IMatch from scratch + new database is enough to get this issue.

force update creates again tmp files.
I will do further tests (e.g. other machines, local vs remote files, etc.) and report back.

@mopperle: yes I meant the user dir temp folder (i forgot to add local). It is shown correctly in the screenshots though.
                      you mention ai things, can I disable them?

[sybersitizen]

Here's an old thread on the same subject:

https://www.photools.com/community/index.php?topic=10727.0

I found 50 pli*.tmp files in my folder. All have a Date modified of Feb 13 or later and a file size of 0 bytes. I deleted them and will check periodically to see what actions cause more to appear.

[Mario]

I'm always astonished how fast you reply and how helpful you are or try to be. So first of all: thank you.

I'm just trying to fix this problem. I just don't have anything to work with yet.
I've worked with IMatch for maybe 6 hours yesterday, including indexing a few thousand files, writing back. Then doing the tests with PNG files I've described above. Not a single pli file in TEMP.

I need to do more tests. If somebody has a clue as to when this happens (or sometimes not happens), let me know.

@All: with pli files in TEMP: which virus checker do you use?

[thrinn]

I looked yesterday afternoon and found no pli files at all.
I looked today and found 4 pli files, all with a timestamp around yesterday 21:30 to 22:00. Unfortunately, I don't remember what exactly I was doing at this time.

Today let run Process Monitor run in the background with the following filter settings:


I can see that whenever I switch to a different folder in IMatch a lot of pli files are generated. This happens indepent from the file type I think: I switched between a folder with photos (ARW, JPG) and another folder only with GPX files (which I also manage in IMatch. In both cases, pli files were generated.

But they seem to be very shortlived. For example, for pliA110.tmp, the timestamps between CreateFile and CloseFile only differ by milliseconds. This could explain why normally these files can not be found in the temp folder.



On the other hand, I did find 4 files from yesterday. My guess is that they are only left behind when something "goes wrong" - whatever that might be.

I am only using MS Defender, no separate virus scanner.

So, not really an explanation - some additional puzzle pieces at most.

[mopperle]

@All: with pli files in TEMP: which virus checker do you use?

Unfortunately I currently have to use Norton 360 for another software test.
But even turning it off, on each start of IM such a tmp file is being created.

[Mario]

I can see in process monitor that something creates a PLI file when I switch folders or categories
But IMatch does not create any files when the user switches between folders or categories. It does, however, query a lot of information from the Windows file system, like file timestamps, read-only state etc.  But the file comes and goes quickly, as @thrinn explained above. Maybe the pli foles

I've added some code to the "idle processing" thread in the IMatch engine. The code scans the TEMP folder for pli files and when at least one PLI file is found, it shows a message box so I know.
Now I'm working with IMatch, trying to make a pli file "stick".  So far, I hat one hit, after opening a new App Panel and thus a Chromium instance. But it was not reproducible.

My guess is these are files Windows creates for some purpose, because I see this:



System is working with this file, calling CreateFileMapping and SetEndOfFileInformationFile.
and maybe something external (virus checker, Windows search indexing service, ...) sometimes prevents Windows from deleting these files?

[mopperle]

sometimes prevents Windows from deleting these files?

My guess too. When I yesterday checked for those pli files, their number did not correlate in any way with how often I used IMatch.

[Gerhard]

some updates:
- local or remote files make no difference for me.
- my server shows the same issue.
- deleting "older" tmp files while import is stuck (the 5 min per file issue above) solve that problem and import continues as normal
- Only tmp files with 0 bytes are not deleted. tmp files which are created with a size are correctly deleted shortly after
- files with size sometimes have an ending like .tmp.png and therefore look like images, but are so fast deleted again, that I was not able to verify

[Mario]

I can see that the files are created even when I only hover of the names of folders in the Media & Folders tree? But not always.
I also see these files being created by explorer.exe, without IMatch being involved at all.

[Mario]

I'm now sure that these files are not created by IMatch but by some Windows functions IMatch uses.

When IMatch is not running (!) and I, for example, compile an app in VSCode or just start Affinity Designer, Process Explorer shows many pli* files being created in the TEMP folder (and they are also deleted).

IMatch uses thousands of Windows functions, and dozens dealing with the file system, like determining if a file exists, fetching information about files, scanning folders etc. Any of these Windows functions may be the one creating these pli files. But they are all short-lived - usually.

Now, after compiling IMatch, starting Affinity Designer and Photoshop and Blender, and closing all applications, I have one pli file with 0 bytes in the TEMP folder. And IMatch was not running.

Why Windows apparently fails so often to delete these files on your system, I have no idea.
Maybe virus checker. Maybe Windows Search Indexer. Maybe some other software - who knows?
Maybe schedule a task that deletes files in the TEMP folder frequently or check out System > Storage in Windows 11.
From you mentioning servers and VMs and whatnot, I assume you are an IT person and you will find a solution.

Since this is not an IMatch problem, I consider this solved. I've spent a couple of hours on this already.

[mopperle]

The only thing I was wondering, searching the web for "pli*.tmp" gave no result exept the topic in your forum.
But anyway, I agree with you Mario, dont waste anymore time on this.

[Gerhard]

as my other issue is solved by deleting those tmp files, it is ok for me to automate the clean-up on my own.
Thank you.