Сетевые диски и UNC-пути: типичные ловушки ── как бизнес-приложению работать с файловым сервером (общей папкой)

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

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

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

Предполагаемая среда

Разговор про аутентификацию меняется вместе с предпосылками, поэтому сначала зафиксируем, какую среду мы имеем в виду.

Самая важная развилка в этой статье — домен это или рабочая группа. Варианты учётной записи запуска в главе 3 (учётная запись компьютера и gMSA) имеют смысл только при наличии домена. Без домена вы смещаетесь к главе 4: передавать учётные данные явно. Сначала выясните, что у вас, и уже потом читайте дальше.

Сокращения в этой статье

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

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

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 31, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

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

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

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

Иными словами, Z: — это лишь «сокращение пути, по одному набору на сеанс входа»; за ним всегда стоит UNC-путь. На схеме это выглядит так.

flowchart TB
    subgraph SA["Сеанс входа A ── интерактивный вход пользователя"]
      EXP["Проводник<br/>приложения, запущенные с рабочего стола"]
      ZA["Набор букв дисков этого сеанса<br/>Z: уже подключён к общему ресурсу"]
      EXP --- ZA
    end
    subgraph SB["Сеанс входа B ── служба / Планировщик заданий"]
      SVC["Служба Windows<br/>запланированный пакетный запуск"]
      ZB["Набор букв дисков этого сеанса<br/>Z: не назначена"]
      SVC --- ZB
    end
    UNC["Реальный ресурс общей папки<br/>UNC-путь ── share на fileserver01"]
    ZA -->|"доступен как Z:"| UNC
    ZB -.->|"Z: нет. По UNC-пути доступен"| UNC

Рис. 1. Буквы дисков — по одному набору на сеанс входа, а реальный UNC-путь один.

Важно: это разделение не потому, что «пользователь другой». Даже если службу настроить на ту же учётную запись, что и сеанс A, система создаёт для службы новый сеанс входа, и подключение из сеанса A туда не переносится.² Типичная жалоба «у службы тот же пользователь, что у меня, а Z: всё равно не находится» как раз из этой путаницы.

Отсюда цепочкой объясняются симптомы, которые на практике встречаются снова и снова.

Историю с 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 есть API WNetGetUniversalName.¹⁵

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

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

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

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

Отсюда три рабочих правила:

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

У gMSA есть предпосылки. Выше сказано «основной вариант», но это не то, что включают в тот же день, когда идея пришла в голову. gMSA изначально расширяет возможности sMSA (standalone Managed Service Account, изолированной управляемой учётной записи службы) с одной машины на несколько серверов: это доменная учётная запись с автоматическим управлением паролем и упрощённым управлением SPN.¹ Перед внедрением проверьте следующее.

Пунктов, которые нужно согласовать с администратором домена, здесь несколько, поэтому если вы предлагаете проект с gMSA, сначала покажите инфраструктуре эти пять пунктов. Если подтверждения нет или десять часов ожидания не влезают в график, соберите систему на обычной доменной учётной записи и оставьте смену на gMSA сменой только учётной записи запуска.

Как строить саму службу (учётная запись запуска, параметры восстановления, безопасная остановка) — в статье «Как создавать и эксплуатировать службу 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). Официальная документация тоже рекомендует олицетворение вместо того, чтобы служба держала собственные учётные данные.² Как правильно писать олицетворение и какие дополнительные оговорки появляются на удалённых ресурсах — в статье «Как правильно работать с токенами олицетворения Windows».

Диагностика своей среды ── какие команды бить первыми

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

Главное — выполнять в том же контексте. net use с вашего рабочего стола ничего не говорит о соединениях службы. Чтобы посмотреть от учётной записи запуска службы, временно зарегистрируйте в Планировщике заданий задачу с той же учётной записью и теми же правами, например cmd /c "whoami > C:\temp\who.txt & net use >> C:\temp\who.txt", и смотрите выходной файл.

Как воспроизвести ошибку 1219 у себя

1219 быстрее «садится» в голове, если один раз получить её самому, а не только прочитать описание. На машине в домене подключитесь к двум общим ресурсам одного файлового сервера под разными учётными данными.

:: 1) Подключаемся к первому ресурсу под своей учётной записью (пароль * — ввод с приглашения)
net use \\fileserver01\share1 * /user:CONTOSO\tanaka

:: 2) Пытаемся подключить другой ресурс того же сервера под другой учётной записью
net use \\fileserver01\share2 * /user:CONTOSO\svc-file
::    → здесь вернётся процитированная выше ошибка 1219, соединение не установится

:: Уборка: рвём все сетевые соединения этого сеанса
net use * /delete

Суть: даже если ресурсы разные, при одном сервере будет конфликт. Что первое — share1, а второе — share2, не важно. Ограничение действует на уровне сервера. Наоборот, если сначала разорвать первое соединение net use \\fileserver01\share1 /delete и потом установить второе, оно пройдёт — то есть в зависимости от порядка всё может «случайно сработать», поэтому на разработке симптом не ловится и всплывает уже в бою. Если обходите это IP-адресом или псевдонимом, не забудьте про SPN, о котором речь чуть выше.¹⁰²¹

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

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

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

Этот таймаут можно изменить. Но таймеры стоят и на сервере, и на клиенте, и побеждает более короткий.¹²

Легко пропустить последнюю строку. Клиентское значение по умолчанию — 10 минут, короче серверных 15, поэтому если удлинить только сервер, поведение разрыва не изменится. Сеанс рвётся по более короткому из autodisconnect и KeepConn.¹²

И всё же менять эти значения — не первый выбор. Разрыв — штатное поведение, при следующем обращении соединение поднимается, обычно вреда нет. Крутить значения имеет смысл, только если на руках старое приложение, которое падает на каждом разрыве и его нельзя трогать, — и то по согласованию с администратором сервера, потому что настройка задевает и другие системы. Со стороны приложения правильный путь — повторять операции, исходя из того, что соединение рвётся.

Второе: ошибки сообщаются неинформативно. 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
    {
        // Если сдаёмся и пробрасываем исключение, по возможности убираем временный файл
        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 и одновременная работа нескольких пользователей
• Как правильно работать с токенами олицетворения 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, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.