2012-06-23 2 views
0

Эмуляция многопоточности путем многократной загрузки DLL (она предназначена для этого). Так как LoadLibrary() на самом деле не позволяет этого, DLL копирует себя во временный файл через GetTempPath() и GetTempFileName().Временные файлы и папки для Windows

Это небольшой файл, и при уничтожении потока он освобождает библиотеку и удаляет временный файл. Проблема заключается в том, что количество потоков настраивается (маньяки могут выбирать 50, 100 и более), что в основном подвергает риску работу нестабильной, аварийной ситуации и не проходит обычную процедуру «удалить временные файлы».

Все в порядке, если я просто оставлю эти временные файлы, чтобы умереть там? ОС обычно очищает само по себе? Или я должен написать процедуру автозапуска? Если да, как я могу сэкономить еще один временный файл, чтобы сохранить список с этими файлами, а не ударять ограничения UAC или иначе?

Любые идеи?

ответ

4

Ваша загрузочная библиотека/многопоточное обсуждение оставляет меня в замешательстве, но это нормально.

Временные файлы в Windows обычно не удаляются ничем, кроме процесса, который их создал. Если пользователь запускает утилиту «Очистка диска» или аналогичный инструмент, он может получить эти файлы, автоматически удаленные для него. Я не думаю, что это происходит слишком часто.

Лучший подход. Предложите вашему приложению создать подкаталог в папке temp (и, возможно, вложенных папок для каждого экземпляра процесса). Когда приложение выходит, оно очищает собственный набор файлов temp через DeleteFile. При повторном запуске приложения у него может быть некоторая логика для очистки папок и файлов, которые все еще задерживаются в результате предыдущего сбоя процесса.

Вы также можете посмотреть, как использовать флаг FILE_ATTRIBUTE_TEMPORARY в CreateFile.

Вы также можете рассмотреть возможность использования глобального обработчика исключений для вашего процесса. Обработчик удалит свою собственную временную директорию, прежде чем выйти из нее.

+0

Будет ли глобальный обработчик исключений также учитывать, что процесс явно убит другим процессом? Можете ли вы дать больше информации? Хороший совет в подкаталоге кстати. –

1

Можете ли вы использовать параметр FILE_FLAG_DELETE_ON_CLOSE для CreateFile?

+0

Кажется, сталкивается с 'LoadLibrary()'; 'CreateFile() -> LoadLibrary()' получает нарушение доступа. 'LoadLibrary() -> CreateFile()' сбой программы. 'CreateFile() -> CloseHandle() -> LoadLibrary() Ошибка загрузки, потому что файл удаляется преждевременно. –

+0

Нарушение совместного доступа может быть связано с тем, что FILE_SHARE_DELETE не указан в аргументе CreateFile sharemode (третий аргумент). Всякий раз, когда файл открывается, предоставляют те же аргументы CreateFile. hfile = CreateFile (L "filename.txt", GENERIC_READ | GENERIC_WRITE | DELETE, FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE, ...) – RoyalJai

+0

Нет, он все равно не позволит LoadLibrary делать свою работу. Если я переключу порядок и передаю 'OPEN_EXISTING' вместо' CREATE_ALWAYS', он действительно работает, за исключением того, что он позволяет там делать файлы, даже после закрытия всех дескрипторов. –