CreateFile. Флаг FILE_FLAG_DELETE_ON_CLOSE
Потом получаю хендл своей копии с помощью CreateFile. Вызов функции следующий:
NULL,FILE_SHARE_DELETE,NULL,OPEN_ALWAYS,
FILE_FLAG_DELETE_ON_CLOSE,NULL);
Судя по МСДН, Винда должна удалить этот файл после того, как никто не будет использовать его хэндл, собственно все так и происходит.
Но есть одна проблема. Я не могу запустить этот файл, хотя и выставил флаг FILE_SHARE_DELETE, о котором МСДН считает:
[QUOTE=MSDN]Enables subsequent open operations on a file or device to request delete access.
Otherwise, other processes cannot open the file or device if they request delete access.
If this flag is not specified, but the file or device has been opened for delete access, the function fails.
Note Delete access allows both delete and rename operations.[/QUOTE]
Что я делаю не так?
Винда XP SP3, Компилятор Builder XE.
___________________________________________
UPD Писал вместо флага FILE_SHARE_DELETE численное значение, взятое из МСДН.
Пытался сохранять файл как *.txt, например, но итог тот же. Сообщение от Винды, мол,
[QUOTE=Windows]The process cannot access the file because it is being used by another process[/QUOTE]
Такое бывает, если вместо флага FILE_SHARE_DELETE выставить NULL. Но у меня не нуль же!
___________________________________________
UPD Пытаюсь реализовать написанное тут, написанное в разделе The DELETE_ON_CLOSE method
А для выполнения файла надо дать возможность чтения из него, чтобы система могла его замапить. Флаг FILE_SHARE_READ.
Всё писал по памяти и по логике, в MSDN лезть лень. :)
Таки открывается, если ставить флажек FILE_SHARE_READ, но после этого в упор перестает удаляться. Ничего понять не могу.
Нашел исходный вариант от Рихтера. Все работает. Там вызов происходит почти как у меня, только с заменой FILE_SHARE_DELETE на, как вы заметили, FILE_SHARE_READ. Но какого у меня после запуска файла он не удаляется (даже если в эксплорере клацнуть), а у Рихтера все нормально? Подозреваю, что проблема в вызове моего файла. Буду копать дальше.
Чудна логика системных программистов, однако.
Временный *.exe (в том случае *.tmp файл) не удаляется, как и у меня во второй раз (с флагом доступа FILE_SHARE_READ). Может, это связно с версией Windows, не знаю. На 2000 возможности проверять нет, да и для мазохистов это :)
Придется как всегда старые добрые *.bat-файлы использовать, или дальше ковырять Апишки.
Тему можно прикрывать.
Поздравляю! Ты раскрыл грязный заговор разработчиков инсталляторов, "забывающих" удалить временные файлы. И пусть не оправдываются -- нет им пощады. Уж инсталляторописатели-то обязаны быть гуру копирования файлов. Благодаря тебе мы теперь знаем причину, по которой они пополнили ряды ЛГБТ. :)
С выходом Висты маркетологи сильно хвалили транзакционные возможности новой NTFS. Мол, раньше фигня была (а ведь кто-то ещё помнит восторги 1996 года), а теперь мы ещё круче забабахали, аж кучу новых функций добавить пришлось.
Сам не изучал по причине отсутствия платформы. :)
Ладно бы инсталяторы. Там всегда можно поставить с MoveFileEx в нуль флажек MOVEFILE_DELAY_UNTIL_REBOOT. Проблема с серверами, которым перезагрузка противопоказана.
С выходом Висты маркетологи сильно хвалили транзакционные возможности новой NTFS. Мол, раньше фигня была (а ведь кто-то ещё помнит восторги 1996 года), а теперь мы ещё круче забабахали, аж кучу новых функций добавить пришлось.
Сам не изучал по причине отсутствия платформы. :)
Проблема в том, что пока есть поддержка XP|2003 сервера от Микрософта все остается печальным и на транзакции можно только облизываться.
___________________________________
UPD Кстати, отличие транзакций только в том, что они оформлены как транзакции. Это все равно не позволит удалить файл через n-ное время, ибо схлопочешь старую добрую ошибку. Вся фишка только в самом оформлении этого действа в системе. Типа более безопасно и так далее. Транзакция субмитятся и только потом вступает в силу изменение. Суть примерно такая. К чему она тут я не понял.