0

Emulating multithreading by loading a DLL multiple times (it's designed for this). Since LoadLibrary() doesn't really allow it, the DLL copies itself into a temporary file, via GetTempPath() and GetTempFileName().

It's a small file and upon thread destruction it frees the library and deletes the temporary file. Problem now is that the number of threads is configurable (maniacs can pick 50, 100, more) which basically exposes the risk of running unstable, crash and not go through the usual "delete temporary files" routine.

Is it okay if I just leave those temporary files to die there? Does the OS usually clean the up by itself? Or should I write an autocleanup routine? If yes, how can I go about saving another temporary file to hold a list with those files, and not hit UAC restrictions or otherwise?

Any ideas?

Silviu-Marian
  • 10,565
  • 6
  • 50
  • 72

2 Answers2

4

Your LoadLibrary/multithreaded discussion leaves me confused, but that's ok.

Temp files on Windows don't generally get deleted by anything other than the process that created them. If the user runs the "Disk Cleanup" util or similar tool, he might be able to get those files automatically deleted for him. I don't think that happens too often.

Best approach. Have your application create a sub-directory within the temp folder (and possibly subfolders for each process instance). When you application exits, it cleans up it's own set of temp files via DeleteFile. On app re-start it can have some logic to cleanup folders and files still lingering around as a result of a previous process crashing.

You could also look at using the FILE_ATTRIBUTE_TEMPORARY flag on CreateFile.

You could also consider having a global exception handler for your process. The handler would delete it's own temp directory before exiting on a crash.

selbie
  • 100,020
  • 15
  • 103
  • 173
  • Would the global exception handler also account for process being explicitly killed by another process? Can you give more info? Good tip on the subdirectory btw. – Silviu-Marian Jun 24 '12 at 13:32
1

Can you use FILE_FLAG_DELETE_ON_CLOSE parameter to CreateFile?

RoyalJai
  • 86
  • 2
  • Seems to collide with `LoadLibrary()`; `CreateFile() -> LoadLibrary()` gets a sharing violation. `LoadLibrary() -> CreateFile()` crashes the program. `CreateFile() -> CloseHandle() -> LoadLibrary()` load fails because file gets deleted prematurely. – Silviu-Marian Jun 24 '12 at 11:32
  • The sharing violation may be because FILE_SHARE_DELETE is not specified in CreateFile argument sharemode (3rd argument). Whenever the file is being opened provide the same arguments to CreateFile. hfile = CreateFile(L"filename.txt", GENERIC_READ|GENERIC_WRITE|DELETE, FILE_SHARE_READ|FILE_SHARE_WRITE|FILE_SHARE_DELETE, ...) – RoyalJai Jun 24 '12 at 12:17
  • No, it still won't allow LoadLibrary to do its thing. If I switch the order and pass `OPEN_EXISTING` instead of `CREATE_ALWAYS` it does work, except it lets the files there, even after all handles were closed. – Silviu-Marian Jun 24 '12 at 13:29
  • CreateFile(L"C:\\Temp\\temp1.txt", GENERIC_READ|GENERIC_WRITE|DELETE|GENERIC_EXECUTE, FILE_SHARE_READ|FILE_SHARE_WRITE|FILE_SHARE_DELETE, NULL, OPEN_ALWAYS, FILE_FLAG_DELETE_ON_CLOSE, NULL); I have replaced OPEN_EXISTING with OPEN_ALWAYS. – RoyalJai Jun 25 '12 at 05:58
  • Nope, no deletion. Not even with the handle explicitly closed last. – Silviu-Marian Jun 25 '12 at 14:35
  • This should mean some other process has a handle to file. Can you install procmon and add a filter for the file, if there are processes that have a handle to the file those will show up. – RoyalJai Jun 25 '12 at 18:02
  • It's the only process. The application has `LoadLibrary()` and `CreateFile()`, then destructor calls `FreeLibrary()` and `CloseHandle()` I Ctrl+F'd on the whole process list, just in case. There's nothing in there, all handles close properly. I also tried `FreeLibrary(hLib); Sleep(3000); CloseHandle(hFile); ` and still nothing. – Silviu-Marian Jun 25 '12 at 18:28