Ошибка Directory.CreateDirectory с путем UNC

У меня есть служба Windows, работающая под определенной учетной записью. Служба создает папку по заданному пути и позже записывает сообщения в эту папку.

Настроенный путь является путем UNC, но был сопоставлен. Когда я развертываю службу на тестовом сервере, я получаю сообщение об ошибке - "не удалось найти часть пути 'Z:\<some folder>'.

Итак, чтобы быть ясным

Server1 - server on which service is insalled and running under `<Domain1>\<User1>` account
Server2 - \\Server2\LogMessages

<Domain1>\<User1> account has full permissions on \\Server2\LogMessages. 
Also \\Server2\LogMessages path has been mapped to "Z:\" on Server1.

Я попытался зарегистрировать идентификатор потока, под которым выполнялся код, и добавил код в журнал.

Thread.CurrentPrincipal.Identity.Name

Идентификационное имя потока возвращено пустым. Я думал, что это должна быть учетная запись, под которой работает служба Windows (в данном случае «Domain1\User1»).

Я в замешательстве и мне нужна помощь, чтобы понять, что происходит. Спасибо.


file-io c# windows-services directory
person stackoverflowuser    schedule 21.02.2012    source источник
comment
Вы должны установить принципала потока при его создании в некоторых случаях. См. stackoverflow.com /questions/6699440/ для примера. Это помогает?   -  person dash    schedule 22.02.2012
comment
Когда вы смотрите на диспетчер задач, показывает ли он, что ваша служба работает под указанной учетной записью (учетной записью, которая сопоставила диск)? Есть разрешения SHARE и разрешения NTFS. Убедитесь, что у вас установлены оба.   -  person Tung    schedule 22.02.2012

Ответы (2)


arrow_upward
0
arrow_downward

Служба работает под определенным пользователем (службы или система), а не под конкретным пользователем. Это распространенная ошибка, так как кажется, что служба работает под определенным пользователем (тот, который ее запустил) Z: отображается в определенной учетной записи пользователя, и служба не может его видеть. Я предлагаю использовать абсолютные пути или общаться через файловую систему или Tcp/IP.

person Mudx    schedule 21.02.2012
comment
Оп упомянул, что его служба работает под определенной учетной записью. Я думаю, что это учетная запись, которую он использовал для подключения диска. Если это так, то его служба должна это видеть - person Tung; 22.02.2012

arrow_upward
0
arrow_downward

Как отметил @Mudx, на самом деле это не проблема с путями UNC, а проблема с привязанными к учетной записи подключенными дисками. Сопоставление сохраняется в кусте реестра вашего пользователя. Альтернативой тому, чтобы полагаться на подключенный диск, является чтение вашей службой файла конфигурации, чтобы определить, где она должна вести журнал. Это может быть простой файл с одним вкладышем, или вы можете добавить свойство в свой файл service.exe.config или создать файл xml, который впоследствии можно будет использовать для настройки других свойств для вашей службы в будущем.

person Tung    schedule 21.02.2012
comment
Путь к файлу задается во время установки и сохраняется в файле конфигурации службы вместе со всеми остальными записями. Мне до сих пор не ясно, почему идентификатор потока должен быть пустым и не установлен для учетной записи, под которой работает служба !! - person stackoverflowuser; 22.02.2012
comment
Эта статья объясняет, что принцип не устанавливается автоматически. Dash также связал предыдущую ветку с упоминанием обходного пути. - person Tung; 22.02.2012
comment
Могу я спросить, почему вы не выбрали доступ к своему местоположению журнала через путь UNC (сохраните путь UNC в своей конфигурации вместо подключенного диска). Если во время установки ваш конечный пользователь выбирает подключаемый диск, вы можете преобразовать этот подключаемый диск в его эквивалент UNC ссылка - person Tung; 22.02.2012