Подводные камни сетевых дисков и UNC-путей ── как бизнес-приложения работают с файловым сервером (общей папкой)

«На машине разработчика всё работало, а у заказчика выдаёт „Z:\ не найден“». «Стоило перенести задачу в Планировщик заданий - и вывод в общую папку начал падать». «Как только сделали Windows-службу, файловый сервер перестал быть виден». В консультациях по бизнес-приложениям проблемы, связанные с файловым сервером (общей папкой), - это едва ли не самая типичная категория трудностей. Приём данных заказов, вывод отчётов и CSV, наблюдение за файлами, которые выкладывает оборудование, - в локальных (on-premises) бизнес-системах общая папка и сегодня остаётся вполне рабочим инструментом интеграции.

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

В этой статье, ориентируясь на разработчиков бизнес-приложений (WinForms/WPF/службы Windows), которым нужно реализовать вывод, приём или наблюдение за файлами в общей папке, мы разберём подводные камни сетевых дисков и UNC-путей на уровне устройства системы и соберём практические правила в виде таблицы решений.

1. Сначала вывод

• Буква диска (Z: и подобные) - это не общесистемный ресурс, а ресурс, привязанный к сеансу входа в систему. Каждому сеансу входа выделяется собственный полный набор букв дисков от A до Z, поэтому диск, подключённый пользователем, невидим для процесса, работающего под другим пользователем, и для службы, работающей в другом сеансе входа.¹
• Если для администратора включён UAC, создаются два сеанса входа - обычный и повышенный, - и подключения дисков (символические ссылки DosDevices) независимы для каждого сеанса. Именно поэтому возникает ситуация «Z: пропадает только в приложении, запущенном с повышением прав». Существует обходной путь через параметр реестра EnableLinkedConnections, который делает подключение общим для обоих сеансов, но Microsoft прямо указывает, что это неподдерживаемый параметр, который «может снизить безопасность системы».²³
• Когда служба (или любой процесс, работающий в другом контексте безопасности) обращается к удалённому ресурсу, официальная рекомендация - использовать UNC-путь (\\server\share\...). Подключение буквы диска изнутри службы через net use или функции WNet не рекомендуется - из-за риска утечки учётных данных и взаимного влияния служб друг на друга.¹
• То, кому нужно выдать права на стороне общего ресурса, определяется учётной записью запуска службы. LocalSystem и NetworkService в сети аутентифицируются как «собственные учётные данные компьютера», а LocalService предъявляет анонимные учётные данные и непригодна для доступа к общим ресурсам. Служба, работающая под локальной учётной записью пользователя, вообще не может обращаться к сетевым ресурсам. На практике реальный выбор - это доменная учётная запись или gMSA, позволяющая переложить управление паролем на ОС.⁴⁵⁶⁷⁸
• Нельзя одновременно удерживать соединения с одним и тем же сервером под двумя разными наборами учётных данных. Второе соединение завершится ошибкой 1219 (ERROR_SESSION_CREDENTIAL_CONFLICT), и это поведение заложено намеренно (by design).⁹¹⁰
• «Медленно, обрывается, иногда недоступен» - нормальное поведение общей папки, а не исключение. Простаивающее соединение по умолчанию отключается сервером через 15 минут (и незаметно восстанавливается при следующем обращении). File.Exists при нехватке прав или иной ошибке возвращает false, не выбрасывая исключение, поэтому не позволяет отличить «файла нет» от «сервер недоступен».¹¹¹²
• FileSystemWatcher поддерживает наблюдение за сетевым диском и удалённым компьютером, но проектировать нужно с расчётом на потерю событий. Переполнение буфера может привести к потере событий, а при наблюдении по сети верхний предел внутреннего буфера ограничен 64 КБ. Совмещение с опросом (полным сканированием) - стандартная практика.¹³

2. Как связаны буква диска и UNC-путь ── Z: принадлежит «вашему сеансу входа»

Когда в Проводнике подключаешь \\fileserver\share к Z:, кажется, будто на всей машине появился «диск Z:». Это первое заблуждение.

Официальная документация формулирует это однозначно. Буква диска - не глобальный для системы ресурс: каждому сеансу входа выделяется собственный набор от A до Z. Перенаправленный диск (сетевой диск) нельзя разделить между процессами, работающими под разными учётными записями, а служба, работающая в другом сеансе входа, не может обратиться к букве диска, установленной в другом сеансе.¹ Система управляет подключениями дисков на основе logon SID, уникально идентифицирующего сеанс входа.¹

Иными словами, Z: - это просто «сокращённое обозначение пути, по одному набору на сеанс входа», а физически за ним всегда стоит UNC-путь. Отсюда цепочкой объясняется целый ряд симптомов, часто встречающихся на практике.

Историю с UAC стоит разобрать чуть подробнее. Когда пользователь из группы администраторов входит в систему, система создаёт два связанных сеанса входа: один с ограниченным токеном, другой - с полным токеном администратора. Физическая сущность подключения диска - объект символической ссылки (DosDevices), связывающий букву диска с UNC-путём; этот объект принадлежит конкретному сеансу входа и не разделяется между сеансами.² Сценарии входа выполняются на стороне обычных прав, поэтому из процесса с повышенными правами это подключение просто не видно - вот и вся логика.

Если установить EnableLinkedConnections (значение DWORD в разделе HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System) равным 1, символическая ссылка записывается сразу в оба связанных сеанса, и этот симптом исчезает. Однако официальная документация прямо предупреждает: «этот обходной путь может снизить безопасность системы. Microsoft не поддерживает этот обходной путь, он предоставляется „как есть“».³ Закладывать в окружение заказчика неподдерживаемую настройку реестра - плохое решение для бизнес-приложения. Правильный путь - писать приложение с расчётом на UNC-пути. В официальном руководстве по устранению неполадок перенаправления папок тоже рекомендуется «всегда использовать UNC-пути вместо буквы подключённого диска».³

Реализация при этом простая: достаточно хранить пути в конфигурации в виде UNC.

// appsettings.json ── храним пути в виде UNC, а не буквы диска
{
  "FileTransfer": {
    "IncomingDir": "\\\\fileserver01\\edi\\incoming",
    "ProcessedDir": "\\\\fileserver01\\edi\\processed"
  }
}

Если приложение позволяет пользователю выбрать путь под Z: через диалог выбора папки, нормализация в UNC при сохранении убережёт от поломки, когда позже сменится контекст выполнения. Для преобразования пути с буквой диска в UNC предусмотрена функция WNetGetUniversalName.¹⁴

3. Доступ к общей папке из службы Windows ── UNC обязателен, и «от чьего имени» идёт доступ

Как показано в предыдущей главе, подключённый диск из службы недоступен. Официальная документация указывает, что служба (и любой процесс, работающий в другом контексте безопасности) должна обращаться к удалённым ресурсам по UNC-имени, и прямо не рекомендует реализацию, при которой служба во время выполнения подключает букву диска через net use или функции WNet. Причины, которые там названы: подключение становится видимым другим службам, работающим в том же контексте, учётные данные, переданные в net use, могут утечь за границы службы, а несколько служб, пытающихся установить одно и то же подключение, начинают мешать друг другу ошибкой «уже подключено».¹

Как только путь стал UNC, следующий вопрос - аутентификация. От чьего имени служба обращается к файловому серверу? Это определяется учётной записью запуска, и именно она определяет, кому нужно выдать права на стороне общего ресурса.

То, что LocalSystem и NetworkService выходят в сеть «от имени компьютера», - официально задокументированный факт.⁴⁵ В документации по BITS прямо изложено практическое следствие: если ACL исходного файла ограничивает доступ учётной записью пользователя, служба (аутентифицирующаяся учётными данными компьютера) получит отказ в доступе, а системным учётным записям вообще не следует использовать подключённые диски.¹⁶

Отсюда вытекают три практических правила:

• При первичной диагностике проблемы «после перевода в службу доступ пропал» нужно первым делом проверить учётную запись запуска. То, что работало на рабочем столе под «вашими» правами, в службе проверяется уже под личностью из таблицы выше. Права общего доступа и ACL NTFS нужно проверять именно для этой личности.
• Для долгосрочной эксплуатации в доменной среде учётной записью запуска должна быть доменная учётная запись или gMSA. У gMSA пароль - случайные 240 байт, автоматически меняемые ОС каждые 30 дней, что структурно устраняет инциденты вроде «в понедельник утром всё встало из-за истёкшего пароля учётной записи службы».¹⁵
• В рабочей группе (без домена) аутентификация учётными данными компьютера не работает, поэтому в дело вступают явные учётные данные, о которых пойдёт речь в следующей главе.

О том, как строить саму службу (настройка учётной записи запуска, параметры восстановления, безопасная остановка), мы рассказываем в статье «Как создавать и эксплуатировать службу Windows», а об устройстве сеансов и входа в систему - в статье «Как понимать изоляцию сеансов Windows».

4. Работа с учётными данными ── net use, диспетчер учётных данных и ошибка 1219

Если самой учётной записи запуска нельзя выдать права на стороне общего ресурса (рабочая группа, NAS с собственной системой учётных записей и т. п.), приходится подключаться, явно передавая учётные данные. Основных способов три:

• net use \\server\share /user:... ── устанавливает подключение для данного сеанса входа. Удобно для интерактивной проверки, но, как уже говорилось, выполнение изнутри службы не рекомендуется.¹
• Диспетчер учётных данных (cmdkey) ── команда cmdkey /add:server /user:svc-file /pass:... сохраняет учётные данные, и в дальнейшем при аутентификации к этому серверу они подставляются автоматически.¹⁷¹⁸ Ловушка в том, что хранилище привязано к профилю пользователя, поэтому для использования в службе регистрировать данные нужно именно в контексте учётной записи запуска службы.
• Подключение из кода (WNetAddConnection2) ── позволяет установить подключение к сетевому ресурсу, явно указав учётные данные клиента. Официальная документация тоже упоминает этот способ как одну из стратегий доступа серверного процесса к сетевым ресурсам.¹⁹ Если сделать «подключение без устройства» (deviceless), не назначая буквы диска, доступ остаётся возможным по UNC-пути.

И самая известная ловушка в этой области - ошибка 1219.

Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. (ERROR_SESSION_CREDENTIAL_CONFLICT, 1219)¹⁰

Нельзя из одного и того же сеанса входа установить несколько подключений к одному серверу под разными именами пользователей. Если попытаться подключиться к одному и тому же файловому серверу двумя видами учётных данных - скажем, к отделу продаж под своей учётной записью, а к общему ресурсу для интеграции систем под выделенной учётной записью, - второе подключение упадёт с ошибкой 1219. Официальная документация прямо называет это поведением «by design» (заложенным намеренно), а перечисленные обходные пути - «подключаться по IP-адресу» или «создать отдельный псевдоним DNS», то есть сделать вид, что это другой сервер.⁹

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

Однако псевдоним - это не просто «добавить одну запись CNAME в DNS, и готово». В среде с Kerberos-аутентификацией SMB-клиент пытается аутентифицироваться по SPN (имени субъекта-службы), соответствующему имени цели подключения, поэтому если для псевдонима не зарегистрирован SPN, обращение через CNAME может провалиться уже на этом этапе. Официальное руководство по устранению неполадок тоже называет отсутствие SPN одной из причин и рекомендует настраивать псевдоним не через CNAME в DNS, а как псевдоним имени компьютера командой netdom computername <имя_сервера> /add:<псевдоним>.²⁰ Прежде чем закладывать подключение через псевдоним в архитектуру как способ обхода ошибки 1219, обязательно проверьте его работоспособность в целевом окружении.

Ещё один момент: продвинутое требование «пусть служба обращается к файловому серверу с правами того клиентского пользователя, который к ней подключился» - это область не переиспользования учётных данных, а impersonation. Официальная документация тоже рекомендует именно impersonation вместо того, чтобы служба держала собственные учётные данные.¹ О правильной реализации impersonation и о дополнительных нюансах для удалённых ресурсов рассказано в статье «Как правильно работать с токенами impersonation в Windows».

5. Проектируем с расчётом на «медленно, обрывается, иногда недоступен»

Код, написанный с тем же настроем, что и для локального диска, рано или поздно обязательно сломается на общей папке. Есть три реальности, которые нужно закладывать заранее.

Во-первых, разрыв соединения - это нормально. Простаивающее соединение по умолчанию отключается через 15 минут таймаута - чтобы не тратить впустую ресурсы сервера. Это тот самый знакомый красный крестик на значке сетевого диска в Проводнике, а при следующем обращении подключение оперативно восстанавливается.¹¹ Иными словами, и то, что бизнес-приложение, обращающееся к папке нечасто, при каждом обращении на мгновение подвисает, и то, что инструмент мониторинга «кричит»: «отключено!» - хотя реального вреда нет, - оба этих явления являются штатным поведением системы. Судить нужно не по наличию подключения, а по тому, успешно ли проходит реальная операция ввода-вывода.

Во-вторых, ошибки сообщаются неинформативно. File.Exists возвращает false без исключения независимо от того, некорректен ли путь, не хватает ли прав или произошёл сбой диска.¹² Локально «false значит файла нет» почти никогда не создаёт проблем, но на общей папке в одно и то же false схлопываются и «файла нет», и «сервер недоступен / нет прав», поэтому код, принимающий бизнес-решение на основе Exists, при сетевом сбое тихо завершается успешно как «объект не найден» - неприятный сценарий поломки. Более пригодная для диагностики на общей папке схема - открывать файл напрямую, без предварительной проверки существования, и различать случаи по типу исключения.

В-третьих, ресурс на другой стороне может ещё отсутствовать. Сразу после загрузки машины запуск службы может опередить готовность сети, да и сам файловый сервер может быть в процессе перезапуска. Персистентное подключение (persistent connection) - это механизм, восстанавливаемый при входе пользователя в систему,²¹ поэтому в мире службы, которая никогда не проходит через вход в систему, нет гарантии, что «после запуска общий ресурс сразу виден». Правильное поведение - не проверить связь один раз при старте и завершиться при неудаче, а повторять попытки, ожидая готовности.

Если заложить все три момента, каркас стороны записи выглядит так:

// Временные сетевые ошибки повторяем, бизнес-ошибки завершаем немедленно
private static async Task WriteToShareAsync(string finalPath, byte[] content, CancellationToken ct)
{
    var dir = Path.GetDirectoryName(finalPath)!;
    var tempPath = Path.Combine(dir, $"~{Guid.NewGuid():N}.tmp");

    try
    {
        for (var attempt = 1; ; attempt++)
        {
            try
            {
                await File.WriteAllBytesAsync(tempPath, content, ct);
                File.Move(tempPath, finalPath); // rename в той же директории публикует "завершение"
                return;
            }
            catch (IOException ex) when (attempt < 5 && IsRetryable(ex))
            {
                // Повторяем только временные сетевые сбои с экспоненциальной задержкой (с ограничением попыток)
                _logger.LogWarning(ex, "Не удалось записать в общий ресурс (попытка {Attempt}). Повторяем", attempt);
                await Task.Delay(TimeSpan.FromSeconds(Math.Pow(2, attempt)), ct);
            }
        }
    }
    catch
    {
        // Если сдаёмся и пробрасываем исключение дальше, best-effort чистим временный файл
        try { File.Delete(tempPath); } catch { /* Ошибку очистки игнорируем */ }
        throw;
    }
}

// IOException прилетает с одним и тем же типом и при "разрыве сети", и при "файле с тем же
// именем в месте назначения", и при "переполненном диске". По младшим 16 битам HResult
// (код ошибки Win32) отбираем только те временные сбои, для которых повтор имеет смысл
private static bool IsRetryable(IOException ex)
{
    var win32 = ex.HResult & 0xFFFF;
    return win32 is 53   // ERROR_BAD_NETPATH: сетевой путь не найден
              or 59   // ERROR_UNEXP_NET_ERR: непредвиденная сетевая ошибка
              or 64   // ERROR_NETNAME_DELETED: сетевое имя больше не доступно
              or 121; // ERROR_SEM_TIMEOUT: истёк тайм-аут (так называемый semaphore timeout)
}

Важно и не писать небрежно «раз это IOException - повторяем». Ошибки, результат которых не изменится сколько ни повторяй - файл с тем же именем уже есть в месте назначения, путь слишком длинный, диск переполнен, - прилетают точно тем же типом IOException, поэтому судить только по типу исключения означает пять раз повторять постоянную ошибку, впустую выжидая экспоненциальную задержку. Как в примере выше, отбирайте по коду ошибки Win32 (53/59/64/121 и подобные коды разрыва/тайм-аута для доступа к общему ресурсу²²) только те сбои, «для которых повтор действительно имеет смысл». Реалистичный подход - постепенно дополнять этот список кодами, которые реально наблюдаются в логах боевого окружения.

Суть не столько в самом добавлении повторов, сколько в том, чтобы сочетать повторы с протоколом передачи, безопасным для повторного выполнения (temp -> rename, идемпотентность). Если запись прервётся на середине, останется недописанный файл. Если договориться, что конечное имя появляется только через rename после закрытия файла, это защитит принимающую сторону от чтения «сырого» файла. Учтите также, что при аварийном завершении процесса или отключении питания код очистки внутри функции просто не выполнится, поэтому стоит предусмотреть и периодическую очистку папки обмена - «удалять файлы ~*.tmp, которые давно не обновлялись», - чтобы мусор не накапливался и не забивал папку. Полная картина этой схемы передачи собрана в статье «Основы блокировок для файловой интеграции».

Есть ещё одна особенность, характерная именно для сети. Результат «неудача» не гарантирует, что неудача действительно произошла. Если соединение обрывается сразу после того, как на стороне сервера завершился rename, клиент может получить исключение, хотя файл под конечным именем уже опубликован. Если в этом состоянии бездумно повторить попытку, можно либо упереться в ошибку «файл с таким именем уже есть в месте назначения», либо - если принимающая сторона уже забрала первый файл - опубликовать те же данные повторно. Решение - перед повтором неудавшегося шага rename проверить состояние места назначения и сверить его. Если включить в конечное имя идентификатор обработки (номер накладной или GUID выполнения), можно распознать ситуацию «конечный файл с этим же ID уже существует» как признак того, что предыдущий rename на самом деле прошёл успешно, и выйти, засчитав операцию как успешную; а принимающая сторона по тому же ID сможет отбросить повторный приём.

6. Блокировки через SMB и надёжность FileSystemWatcher

6.1. Не стоит слишком полагаться на блокировки

К общей папке одновременно обращается несколько клиентов. Открытие с FileShare.None действительно даёт эксклюзивность, пока дескриптор открыт, даже через SMB, но проектирование, опирающееся на «если блокировка получена - значит безопасно», рушится, когда дескриптор теряется из-за разрыва соединения или когда в дело вмешивается участник, не берущий блокировку (ручное копирование, другая система). Настоящую основу взаимного исключения стоит строить не на блокировке ОС, а на самом протоколе передачи: temp -> rename, атомарный claim (обрабатывает только тот, кто выиграл rename из incoming в processing) и идемпотентность. Подробности этого подхода - в статье о блокировках, упомянутой выше.

6.2. Реальность использования FileSystemWatcher на удалённом общем ресурсе

FileSystemWatcher официально документирован как поддерживающий наблюдение за файлами не только локально, но и на сетевых дисках и удалённых компьютерах.¹³ Само по себе его использование оправдано. Однако есть два предостережения о надёжности.

• Уведомления приходят через буфер, и переполнение приводит к их потере. Если изменения происходят кучно за короткое время, события сверх размера буфера теряются.¹³
• При наблюдении по сети верхний предел InternalBufferSize ограничен 64 КБ. Это ограничение «нельзя раздуть больше», в отличие от локального наблюдения, зафиксировано явно.¹³

К тому же в практике расследования сбоев я неоднократно видел ситуацию, когда при перезапуске или разрыве соединения с сервером на другой стороне наблюдатель просто молча умирает, и никакого уведомления об этом не приходит вовсе. Практический вывод - относиться к FileSystemWatcher на удалённом общем ресурсе как к „подсказке для более быстрой реакции“, а источником истины считать полное сканирование (опрос) при запуске, при ошибке и по расписанию. Схемы проектирования, включая обработку дублирующихся и приходящих не по порядку событий, подробно разобраны в статье «Практическое руководство по FileSystemWatcher».

7. Практические правила (таблица решений)

Сведём всё изложенное выше в таблицу решений по спорным вопросам проектирования.

Последняя строка требует пояснения. Интеграция через общую папку удобна, но чем больше точек доступа, тем экспоненциально сложнее становится управление тем, «у кого какие права» и «кто с кем конфликтует». После определённого масштаба стоит свести процесс, обращающийся к файловому серверу, в единую службу Windows, а каждому клиенту общаться с ней по HTTP или gRPC. Понижение статуса общей папки с «интерфейса между системами» до «внутренней реализации этой одной службы» в долгосрочной перспективе оказывается наиболее удобной в сопровождении формой.

8. Итог

• Буква диска - лишь символ, привязанный к сеансу входа. То, что она невидима для другого пользователя, повышенного процесса или службы, заложено намеренно, и правильный путь - писать приложение с расчётом на UNC-пути. EnableLinkedConnections - неподдерживаемый обходной путь.
• Доступ к общему ресурсу из службы требует UNC. От чьего имени идёт аутентификация, определяется учётной записью запуска: LocalSystem/NetworkService используют учётные данные компьютера, LocalService - анонимные. На практике права на стороне общего ресурса выдаются доменной учётной записи или gMSA.
• Одновременные подключения к одному серверу под разными учётными данными завершаются ошибкой 1219 (заложено намеренно). Избегайте этого ещё на этапе проектирования - через объединение учётных записей или псевдоним DNS.
• «Медленно, обрывается, иногда недоступен» - нормальное поведение общей папки. Отключение по простою (по умолчанию 15 минут) - не аномалия, а false от File.Exists неотличим от сетевого сбоя. Закладывайте повторы, temp -> rename и идемпотентность вместе.
• FileSystemWatcher поддерживает удалённое наблюдение, но из-за переполнения буфера и предела в 64 КБ события теряются, поэтому сочетание с полным сканированием - стандартная практика.
• Если сомневаетесь - обращайтесь к таблице решений из главы 7. А когда масштаб вырастет, рассмотрите вариант со сведением доступа к общему ресурсу в промежуточную службу.

Похожие статьи

• Основы блокировок для файловой интеграции - лучшие практики файловых блокировок и атомарного claim
• Практическое руководство по FileSystemWatcher - защита от потерь и дублирования событий
• Как создавать и эксплуатировать службу Windows ── от выбора между Планировщиком заданий и BackgroundService до превращения в службу
• Как понимать изоляцию сеансов Windows ── Session 0, RDP и одновременная работа нескольких пользователей
• Как правильно работать с токенами impersonation в Windows ── заимствование прав на уровне потока и безопасный возврат

Смежные направления консультаций

В KomuraSoft LLC мы занимаемся проектированием и реализацией систем файловой интеграции через общие папки, прорабатываем настройку прав доступа и аутентификации при переводе приложения в службу Windows, а также расследуем сбои вроде «после перевода в службу общий ресурс перестал быть виден» или «падает только в конкретном окружении».

• Разработка Windows-приложений
• Расследование сбоев и анализ первопричин
• Техническая консультация и ревью проекта
• Контакты

Справочные ссылки

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Почему служба Windows не может обратиться к сетевому диску (Z:)?

Потому что буква диска - это не общесистемный ресурс, а ресурс, привязанный к конкретному сеансу входа в систему (logon session). Диск Z:, который пользователь подключил через Проводник, - это лишь символ, принадлежащий сеансу входа этого пользователя, и он невидим для службы, работающей в другом сеансе входа. Даже если служба запущена под учётной записью пользователя, система создаёт для неё новый сеанс входа, поэтому подключение диска на стороне рабочего стола не переносится на эту же учётную запись в службе. Правильный способ для службы - обращаться к ресурсу по UNC-пути \\server\share.

Как службе, работающей под LocalSystem, получить доступ к общей папке?

В сети LocalSystem аутентифицируется как собственные учётные данные компьютера. В доменной среде можно предоставить учётной записи компьютера (DOMAIN\MACHINE$) права на стороне общего ресурса - и в разрешениях общего доступа, и в ACL NTFS. Однако такая схема неудобна в эксплуатации: при замене машины права придётся настраивать заново. Поэтому на практике мы рекомендуем запускать службу под доменной учётной записью или gMSA (групповой управляемой учётной записью службы) и выдавать права на общий ресурс именно этой учётной записи.

Можно ли наблюдать за файлами в общей папке с помощью FileSystemWatcher?

Использовать можно, но полагаться только на него нельзя. FileSystemWatcher официально поддерживает наблюдение за сетевыми дисками и удалёнными компьютерами, но уведомления об изменениях приходят через внутренний буфер, и если уведомления идут потоком, буфер может переполниться и часть событий будет потеряна. Более того, при наблюдении по сети верхний предел размера буфера ограничен 64 КБ. Уведомления стоит рассматривать лишь как повод для повторного сканирования и обязательно сочетать их с полным сканированием (опросом) при запуске, при ошибке и по расписанию.

Как сделать обмен файлами устойчивым к разрывам сети?

Нужно проектировать так, будто «общая папка медленная, соединение рвётся, а сервер иногда недоступен» - это нормальное поведение, а не исключение. Конкретно: запись вести под временным именем файла и переименовывать его в конечное имя только после закрытия дескриптора (temp -> rename), операции чтения и записи оборачивать в повторные попытки, а временные сетевые ошибки отличать от собственно бизнес-ошибок. Важно учитывать, что File.Exists возвращает false даже тогда, когда ресурс просто недоступен, - то есть не позволяет отличить «файла нет» от «сервер не отвечает», - а последним рубежом защиты остаётся идемпотентность обработки, при которой повторная обработка не приводит к порче данных.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.