Чтение файла Windows без запрета записи другим процессом в него [дубликата]

Question

Чтение файла Windows без запрета записи другим процессом в него [дубликата]

1

У меня есть файл, который я хочу прочитать. Файл может быть в любой момент перезаписан другим процессом. Я не хочу блокировать это письмо. Я готов управлять коррупцией для данных, которые я читал, но не хочу, чтобы мое чтение каким-либо образом меняло поведение процесса записи.

Процесс, который записывает файл, - это программа delphi, работающая локально на сервере. Он открывает файл, используя fmCreate. fmCreate пытается открыть файл исключительно и не удается, если в файле есть другие дескрипторы.

Я читаю файл из скрипта python, который удаляет файл удаленно через нашу сеть.

Меня интересует, есть ли решение, независимо от того, поддерживается ли оно python или delphi. Я хочу знать, есть ли способ сделать это под окнами без изменения программы записи.

Изменение: повторить, это не дубликат. Другой вопрос заключался в попытке получить доступ для чтения к файлу, на который записывается. Я хочу, чтобы у автора был доступ к файлу, который я открыл для чтения. Это разные вопросы (хотя я боюсь, что ответ будет схожим, что это невозможно).

Richard A 31 янв. 2013, в 05:12

Источник

0

@HarryJohnston Я думаю, что моя проблема отличается от этого вопроса, я не хочу доступ на чтение к исключительно открытому файлу, я хочу, чтобы файл все еще открывался приложением для записи (исключительно), даже если я пытаюсь его прочитать ( неэксклюзивно).
Richard A 31 янв. 2013, в 08:18
0

@RichardA вам нужно соответствующим образом обновить ваш вопрос, иначе он будет закрыт теми, кто не читает комментарии.
Eugene Mayevski 'Allied Bits 31 янв. 2013, в 08:58
0

Я не думаю, что это имеет какое-либо значение, если ваш процесс или другой процесс открывает файл первым. Ваши варианты в значительной степени одинаковы в любом случае.
Harry Johnston 01 фев. 2013, в 05:43
0

Спасибо, @ EugeneMayevski'EldoSCorp, я только вернулся к этому и был удивлен, увидев, что он был закрыт, так как я уже объяснил, почему это не дубликат.
Richard A 04 фев. 2013, в 00:48
0

Вы пытаетесь увидеть новые данные в режиме реального времени, как они записаны в файл?
Harry Johnston 04 фев. 2013, в 04:29
0

@RichardA Я думаю, что вы можете удалить вопрос и опубликовать новый, перефразируя текст, чтобы он не рассматривался как дубликат. Но если вы проверите мой ответ, вам не нужен еще один вопрос.
Eugene Mayevski 'Allied Bits 04 фев. 2013, в 04:38
0

Я до сих пор не думаю, что имеет какое-то значение, какой процесс открывает файл первым, поэтому ваше дополнительное примечание на самом деле не имеет значения. С другой стороны, вы обращаетесь к файлу удаленно, и вы не исключили драйверов режима ядра, так что, возможно, это не точная копия.
Harry Johnston 04 фев. 2013, в 09:27
0

Короткий ответ: если клиент не имеет административного доступа к серверу, это невозможно сделать удаленно, вам придется установить дополнительное программное обеспечение на сервере, чтобы прочитать файл от имени клиентского процесса. Это могло бы использовать или VSS согласно другому вопросу или драйвер фильтра согласно ответу Юджина.
Harry Johnston 04 фев. 2013, в 09:34
0

@HarryJohnston Набор решений различается в зависимости от того, кто первый, а кто второй, кто открывает файл.
Eugene Mayevski 'Allied Bits 04 фев. 2013, в 11:38
0

@ Евгений: ты можешь это оправдать? Приведите пример решения, которое работает только в одном из этих случаев? (Я уже проголосовал за открытие.)
Harry Johnston 04 фев. 2013, в 20:08
0

@HarryJohnston Это очевидно - если эксклюзивное чтение - это вторая операция (приложение 3-го участника), использование трюков для обхода защиты не будет работать для первой операции открытия (наше приложение). Если приложение 3rdparty откроет файл первым, мы сможем использовать, например. наш RawDisk, чтобы открыть файл, который уже был открыт исключительно.
Eugene Mayevski 'Allied Bits 05 фев. 2013, в 06:33
0

Я не понимаю, почему нет. Если вы можете прочитать файл, не открывая его, почему это может повлиять на другое приложение? Определенные инструменты могут поддерживать только один сценарий, но любой конкретный метод должен быть применим к любому, с небольшими изменениями.
Harry Johnston 05 фев. 2013, в 20:16
0

Спасибо за все обсуждение. @HarryJohnston, я думал, что порядок открытия может иметь значение, так как процесс чтения сначала открывает его неэксклюзивно, затем процесс записи пытается открыть исключительно. Процесс чтения не хочет читать новые данные в режиме реального времени, он готов прервать чтение и попытаться получить доступ к файлу после записи новых данных.
Richard A 11 фев. 2013, в 22:40
0

Я думаю, что рискуя разобраться в этом вопросе, другой вопрос касался попыток прочитать файл, в который производится запись. Я хочу иметь возможность записи в файл, который читается, даже если запись прекращает чтение. Для меня это разные проблемы.
Richard A 11 фев. 2013, в 22:44
0

По вашему вопросу вы хотите прочитать файл. Это кто-то другой (то есть, чей-то другой код), который пишет в него. В Windows я не думаю, что порядок, в котором это происходит, должен иметь большое значение для возможного диапазона решений, или, по крайней мере, не в принципе. OTOH, @Eugene явно более опытен в практических аспектах такого рода хитрости, поэтому есть хороший шанс, что он видит некоторую тонкость, которую я пропустил.
Harry Johnston 12 фев. 2013, в 00:11
0

Для пояснения, в Windows, когда вы получаете блокировку общего доступа к файлу, блокировка обрабатывается совершенно симметрично; то есть вопрос о том, совместима ли ваша блокировка с другой существующей или будущей блокировкой для того же файла, не зависит от того, какая блокировка была первой. Было бы вполне возможно спроектировать операционную систему, в которой это было бы неверно, но это верно для Windows. (Таким образом, единственными вариантами являются либо чтение файла с использованием какого-либо метода, который вообще не получает блокировку, либо изменение другого процесса прямо или косвенно.)
Harry Johnston 12 фев. 2013, в 00:21
0

Я, конечно, не эксперт в этом. Причина, по которой я думал, что было отсутствие симметрии, заключается в том, что читатель открывает файл с помощью OF_SHARE_DENY_NONE, тогда как писатель открывает его с помощью OF_CREATE; поэтому замки не равны.
Richard A 12 фев. 2013, в 03:54
0

Да, но это, по-видимому, верно независимо от того, открывает ли файл сначала читатель или писатель. Они все равно будут использовать одни и те же флаги совместного доступа.
Harry Johnston 12 фев. 2013, в 04:17
0

Я уверен, что ты прав. У меня есть только упрощенное понимание основных функций операционной системы. Я просто надеялся, возможно, наивно, что был какой-то способ позволить одному процессу получить файл, если другой процесс открыл его с правильным флагом. Я думаю, что мои надежды разбиты.
Richard A 13 фев. 2013, в 22:55

Показать ещё 17 комментариев

Теги:

python

windows

delphi

winapi

filesystems

1 ответ

Ещё вопросы

@HarryJohnston Я думаю, что моя проблема отличается от этого вопроса, я не хочу доступ на чтение к исключительно открытому файлу, я хочу, чтобы файл все еще открывался приложением для записи (исключительно), даже если я пытаюсь его прочитать ( неэксклюзивно).
@RichardA вам нужно соответствующим образом обновить ваш вопрос, иначе он будет закрыт теми, кто не читает комментарии.
Я не думаю, что это имеет какое-либо значение, если ваш процесс или другой процесс открывает файл первым. Ваши варианты в значительной степени одинаковы в любом случае.
Спасибо, @ EugeneMayevski'EldoSCorp, я только вернулся к этому и был удивлен, увидев, что он был закрыт, так как я уже объяснил, почему это не дубликат.
Вы пытаетесь увидеть новые данные в режиме реального времени, как они записаны в файл?
@RichardA Я думаю, что вы можете удалить вопрос и опубликовать новый, перефразируя текст, чтобы он не рассматривался как дубликат. Но если вы проверите мой ответ, вам не нужен еще один вопрос.
Я до сих пор не думаю, что имеет какое-то значение, какой процесс открывает файл первым, поэтому ваше дополнительное примечание на самом деле не имеет значения. С другой стороны, вы обращаетесь к файлу удаленно, и вы не исключили драйверов режима ядра, так что, возможно, это не точная копия.
Короткий ответ: если клиент не имеет административного доступа к серверу, это невозможно сделать удаленно, вам придется установить дополнительное программное обеспечение на сервере, чтобы прочитать файл от имени клиентского процесса. Это могло бы использовать или VSS согласно другому вопросу или драйвер фильтра согласно ответу Юджина.
@HarryJohnston Набор решений различается в зависимости от того, кто первый, а кто второй, кто открывает файл.
@ Евгений: ты можешь это оправдать? Приведите пример решения, которое работает только в одном из этих случаев? (Я уже проголосовал за открытие.)
@HarryJohnston Это очевидно - если эксклюзивное чтение - это вторая операция (приложение 3-го участника), использование трюков для обхода защиты не будет работать для первой операции открытия (наше приложение). Если приложение 3rdparty откроет файл первым, мы сможем использовать, например. наш RawDisk, чтобы открыть файл, который уже был открыт исключительно.
Я не понимаю, почему нет. Если вы можете прочитать файл, не открывая его, почему это может повлиять на другое приложение? Определенные инструменты могут поддерживать только один сценарий, но любой конкретный метод должен быть применим к любому, с небольшими изменениями.
Спасибо за все обсуждение. @HarryJohnston, я думал, что порядок открытия может иметь значение, так как процесс чтения сначала открывает его неэксклюзивно, затем процесс записи пытается открыть исключительно. Процесс чтения не хочет читать новые данные в режиме реального времени, он готов прервать чтение и попытаться получить доступ к файлу после записи новых данных.
Я думаю, что рискуя разобраться в этом вопросе, другой вопрос касался попыток прочитать файл, в который производится запись. Я хочу иметь возможность записи в файл, который читается, даже если запись прекращает чтение. Для меня это разные проблемы.
По вашему вопросу вы хотите прочитать файл. Это кто-то другой (то есть, чей-то другой код), который пишет в него. В Windows я не думаю, что порядок, в котором это происходит, должен иметь большое значение для возможного диапазона решений, или, по крайней мере, не в принципе. OTOH, @Eugene явно более опытен в практических аспектах такого рода хитрости, поэтому есть хороший шанс, что он видит некоторую тонкость, которую я пропустил.
Для пояснения, в Windows, когда вы получаете блокировку общего доступа к файлу, блокировка обрабатывается совершенно симметрично; то есть вопрос о том, совместима ли ваша блокировка с другой существующей или будущей блокировкой для того же файла, не зависит от того, какая блокировка была первой. Было бы вполне возможно спроектировать операционную систему, в которой это было бы неверно, но это верно для Windows. (Таким образом, единственными вариантами являются либо чтение файла с использованием какого-либо метода, который вообще не получает блокировку, либо изменение другого процесса прямо или косвенно.)
Я, конечно, не эксперт в этом. Причина, по которой я думал, что было отсутствие симметрии, заключается в том, что читатель открывает файл с помощью OF_SHARE_DENY_NONE, тогда как писатель открывает его с помощью OF_CREATE; поэтому замки не равны.
Да, но это, по-видимому, верно независимо от того, открывает ли файл сначала читатель или писатель. Они все равно будут использовать одни и те же флаги совместного доступа.
Я уверен, что ты прав. У меня есть только упрощенное понимание основных функций операционной системы. Я просто надеялся, возможно, наивно, что был какой-то способ позволить одному процессу получить файл, если другой процесс открыл его с правильным флагом. Я думаю, что мои надежды разбиты.

Eugene Mayevski 'Allied Bits · Answer 1 · 2013-01-31T03-45-00.000Z

Вы можете настроить драйвер фильтра, который может действовать двумя способами: (1) изменить флаги при открытии файла и (2) он может захватить данные, когда он будет записан в файл, и сохранить копию данных в другом месте.

Этот подход гораздо более легкий и эффективный, чем служба теневого копирования томов, упомянутая в комментариях, однако для этого требуется наличие драйвера фильтра. На рынке существует несколько драйверов (т.е. Это продукты, которые включают драйвер и позволяют писать бизнес-логику в пользовательском режиме), но они являются дорогостоящими и могут быть излишним в вашем случае. Тем не менее, если вам нужна вещь только для частного использования, свяжитесь со мной конфиденциально для получения лицензии на наш CallbackFilter.

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

Что касается вашего последнего комментария: конечно, фильтр может извлечь данные из файла, не открывая его, что избавит читателя от необходимости открывать файл вообще?
Спасибо за ответ, Евгений. Я не очень разбираюсь в драйверах фильтров, поэтому ценю лидерство.