Это перевод Is File In Use. Автор: Christian Wimmer.
На форумах DelphiPraxis задали вопрос, который обычно всплывает несколько раз в год. Однако в этот раз я мог сказать, что появился API, который решает эту проблему. Вопрос был о том, как определить, кто держит файл. Главной проблемой стало то, что я никак не мог вспомнить название API, так что Assarbad пришлось постараться и поискать его.
Посмотреть текст целиком...
воскресенье, 19 февраля 2012 г.
суббота, 18 февраля 2012 г.
Как мне найти программу, которая держит этот файл?
Это перевод How do I find out which process has a file open? Автор: Реймонд Чен.
Исторически, нет никакого специального способа найти процесс, который держит файл. Файловый объект имеет обычный счётчик ссылок объекта ядра и когда счётчик опускается до нуля - файл закрывается. Но в системе никто не отслеживает процессы, открывшие данный описатель, и сколько именно раз они его открыли (и это упрощённое изложение даже игнорирует тот факт, что счётчик может быть увеличен вовсе не процессом, а, скажем, драйвером режима ядра; или, быть может, изначально счётчик был увеличен процессом, который теперь уже закрыт, но файл ещё держится драйвером ядра).
Это состояние вещей согласуется с концепцией не хранить информацию, которая вам не нужна. Файловую систему не заботит, кто там держит её файлы. Её задача - закрыть файл, когда уйдёт последняя ссылка.
Аналогичную ситуацию вы видите в COM. Всё, что вас заботит - когда же счётчик опустится до нуля (потому что в этот момент вам нужно удалить объект). Если позже вы обнаружите в своём процессе утечку, то у вас нет никакого волшебного запроса "Покажи мне всех, то вызывал _AddRef для моего объекта" - просто потому, что вы никогда и не вели учёт вызывающих _AddRef. Нет у вас и возможности сделать так: "Вот объект, который я хочу удалить. Покажи мне всех использующих его, так что я смогу их удалить".
По крайней мере таким был классический сценарий.
Посмотреть текст целиком...
Исторически, нет никакого специального способа найти процесс, который держит файл. Файловый объект имеет обычный счётчик ссылок объекта ядра и когда счётчик опускается до нуля - файл закрывается. Но в системе никто не отслеживает процессы, открывшие данный описатель, и сколько именно раз они его открыли (и это упрощённое изложение даже игнорирует тот факт, что счётчик может быть увеличен вовсе не процессом, а, скажем, драйвером режима ядра; или, быть может, изначально счётчик был увеличен процессом, который теперь уже закрыт, но файл ещё держится драйвером ядра).
Это состояние вещей согласуется с концепцией не хранить информацию, которая вам не нужна. Файловую систему не заботит, кто там держит её файлы. Её задача - закрыть файл, когда уйдёт последняя ссылка.
Аналогичную ситуацию вы видите в COM. Всё, что вас заботит - когда же счётчик опустится до нуля (потому что в этот момент вам нужно удалить объект). Если позже вы обнаружите в своём процессе утечку, то у вас нет никакого волшебного запроса "Покажи мне всех, то вызывал _AddRef для моего объекта" - просто потому, что вы никогда и не вели учёт вызывающих _AddRef. Нет у вас и возможности сделать так: "Вот объект, который я хочу удалить. Покажи мне всех использующих его, так что я смогу их удалить".
По крайней мере таким был классический сценарий.
Посмотреть текст целиком...
пятница, 17 февраля 2012 г.
Некоторые папки двигать нельзя - и вам придётся научиться с этим жить
Это перевод Some known folders cannot be moved, but others can, and you'll just have to accept that. Автор: Реймонд Чен.
Некоторые из "известных папок" оболочки (Shell known folders) могут быть помечены как
Эта дихотомия представляется простой и недостойной отдельного обсуждения - за исключением того, что у некоторых клиентов иногда возникают проблемы включения этого понятия в своё мировоззрение.
Посмотреть текст целиком...
Некоторые из "известных папок" оболочки (Shell known folders) могут быть помечены как
KF_CATEGORY_FIXED, что делает их неперемещаемыми. И наоборот, если папка файловой системы не является "неподвижной", то она может быть перемещена.Эта дихотомия представляется простой и недостойной отдельного обсуждения - за исключением того, что у некоторых клиентов иногда возникают проблемы включения этого понятия в своё мировоззрение.
Посмотреть текст целиком...
