Rapid file access creates temporary files. Why?

Windows
1

I have a strange situation, where rapid file accesses creates weird temporary files.
We are using a file to share data between multiple processes, and an InterProcessLock to synchronize the access to the file.

Pseudocode:

String filename = "myFile.file";
const auto mangledStringForLock = generateSomeMangledStringForTheLock(filename);
InterPorcessLock ipl(mangledStringForLock);
while (someCondition)
{
    ipl.enter();
    // open file
    // read / write something
    // close file 
    ipl.exit();
    Thread::sleep(100);
}

This is what I observe in Windows Explorer:
tempFilesCreated
There are temporary files created automatically. When all processes terminate without an error, those temporary files disappear. When a process crashes, sometimes one of these temporary files stays on the disk.
It is worth to note that most of the time, the filename is myFile_temp[something].file, but it can also be myFile.file~[something].TMP (see gif image). It seems like there are multiple things at play here.
I can reproduce the problem even with a single process, if the sleep time is below 100ms.

My questions:

  1. Who is responsible for creating these temp files? I don’t see anything like this in the JUCE code. Also I didn’t find any info if Windows is the culprit here.
  2. Should I care? Is my “data sharing” model at risk? Do I have to transition to shared memory?
2

The file you are seeing is probably from the InterProcessLock.
The platform specific code is a bit hidden on purpose:

I looked into CreateMutexW, and it seems to create a file for the locking, so it is a file based lock on windows:

That means, nothing to worry, but if the processes don’t share the mangledStringForLock, the lock might not have any effect.

3

Thank you for your reply!
Yes, the processes share the string and locking works.

The weird thing is that this temporary file sits in the same folder as my actual data file so I assumed it had to do with the actual file access. If this temp file was from the InterProcessLock , it would need to know where my data file is. But all it can see is the mangled string, which doesn’t contain any usable information.
The code you quoted has nothing to do with actual files, except for what internally happens in CreateMutexW()

So no, I don’t think this file comes from the lock.

4

Ok, was a try… I don’t know what your generateSomeMangledStringForTheLock() returns, so it might have the path taken from your filename. But I see now, that it is a plain String.

Could still use the CWD, but well… good luck!

5

@sparklingRhubarb what is

    // read / write something

doing exactly?

If you are using File::replaceWithData or File::replaceWithText, they both create a temporary file under the hood. See their documentation.