Назад | Перейти на главную страницу

Могут ли несколько компьютеров одновременно добавлять файлы к файлу в общей папке Windows?

Я пытаюсь записать определенную информацию из моей сети компьютеров Windows; Я настроил их на периодический сбор этой информации, а затем я хочу, чтобы она была в одном CSV-файле на сетевом диске. Я использую VBS для сбора этих данных, используя OpenTextFile в режиме добавления для записи. Позволит ли это нескольким компьютерам одновременно добавлять строку в этот файл? Или есть другой способ сделать это (кроме хранения отдельного файла для каждого устройства).

Меня не волнует порядок (я собираю метку времени с каждого устройства).

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

Тем не мение, вы усложняете ситуацию, когда говорите о доступе к файлу в общей сетевой папке. Теперь мы получаем доступ к файлам по сетевому протоколу SMB.

SMB использует блокирует (оппортунистические блокировки) и аренда для управления одновременным доступом к файлам. Типы блокировок и аренды следующие:

Блокировки

  • Уровень 1, эксклюзивный доступ Эта блокировка позволяет клиенту открыть файл для монопольного доступа. Клиент может выполнять буферизацию с упреждающим чтением и кэширование чтения или записи.
  • Уровень 2, общий доступ Эта блокировка позволяет нескольким одновременным читателям файла и запретить запись. Клиент может выполнять буферизацию с упреждающим чтением и кэширование чтения данных и атрибутов файла. Запись в файл приведет к тому, что держатели блокировки будут уведомлены о том, что блокировка была нарушена.
  • Пакетный, эксклюзивный доступ Эта блокировка получила свое название от блокировки, используемой при обработке пакетных (.bat) файлов, которые открываются и закрываются для обработки каждой строки в файле. Клиент может оставить файл открытым на сервере, даже если приложение (возможно, временно) закрыло файл. Эта блокировка поддерживает кэширование чтения, записи и обработки.
  • Фильтр, эксклюзивный доступ Эта блокировка предоставляет приложениям и фильтрам файловой системы механизм для снятия блокировки, когда другие клиенты пытаются получить доступ к тому же файлу, но в отличие от блокировки уровня 2, файл не может быть открыт для доступа к удалению, и другой клиент не получит нарушение обмена. Эта блокировка поддерживает кэширование чтения и записи.

Аренда

  • Чтение (R), общий доступ Позволяет нескольким одновременным читателям файла и не писать. Эта аренда позволяет клиенту выполнять буферизацию с упреждающим чтением и кэширование чтения.
  • Дескриптор чтения (RH), общий доступ Это похоже на оппозиционную блокировку уровня 2, с дополнительным преимуществом, позволяющим клиенту держать файл открытым на сервере, даже если средство доступа на клиенте закрыло файл. (Диспетчер кеша будет лениво сбрасывать незаписанные данные и очищать немодифицированные страницы кеша в зависимости от доступности памяти.) Это превосходит оппортунистическую блокировку 2-го уровня, поскольку нет необходимости прерывать аренду между открытием и закрытием дескриптора файла. (В этом отношении он обеспечивает семантику, аналогичную пакетной оппортунистической блокировке.) Этот тип аренды особенно полезен для файлов, которые многократно открываются и закрываются, поскольку кеш не становится недействительным при закрытии файла и пополняется при повторном открытии файла, обеспечение значительного повышения производительности для сложных приложений с интенсивным вводом-выводом.
  • Чтение-запись (RW), эксклюзивный доступ Эта аренда позволяет клиенту открывать файл для монопольного доступа. Эта блокировка позволяет клиенту выполнять буферизацию с упреждающим чтением и кэширование чтения или записи.
  • Чтение-запись-дескриптор (RWH), эксклюзивный доступ Эта блокировка позволяет клиенту открыть файл для монопольного доступа. Эта аренда поддерживает кэширование чтения, записи и обработки (аналогично аренде Read-Handle).

Windows Internals 6-е изд., Марк Руссинович и др.

Ни один из этих режимов не предоставит вам общего доступа для записи, который вы ищете.

Измени свою стратегию. Как сказал MDMarra, журнал событий Windows - лучший выбор. Другая идея состоит в том, чтобы все клиенты записывали в свои собственные файлы в общей папке, а затем серверный процесс собирал все файлы и объединял их. Вы упоминаете в своем вопросе, что пишете код, поэтому вы можете изменить способ работы этого приложения. Я бы посоветовал зайти в StackOverflow и спросить у них, как лучше всего подойти к общему доступу на запись к одному файлу по сети.

Нет. Когда файл открывается для записи, он блокируется. Другие попытки записи при блокировке приведут к «Доступ запрещен».

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

Другой способ решения этой проблемы может заключаться в том, чтобы каждая машина имела эксклюзивную блокировку файла во время записи и сразу же после этого освобождала его, а также запрограммировала каждую машину с помощью цикла, который пытается получить доступ для записи в файл, и после получения сообщение «доступ запрещен» просто повторяется, пока файл не станет доступным. Этому человеку нужно добавлять сообщения журнала короткой длины в общий файл. Таким образом, каждая машина блокирует файл только на короткое время. Цикл для получения исключительной блокировки записи быстро получит доступ на запись. Если каждый процесс записывает в режиме добавления, я считаю, что это должно обеспечить необходимую функцию, при которой каждая машина добавляет в файл журнала по мере необходимости.