Прерывистое UnauthorizedAccessException, хранящее файлы конфигурации в CommonApplicationData - PullRequest
0 голосов
/ 25 марта 2011

Я создал приложение с локальным хранилищем конфигурации под Environment.SpecialFolder.CommonApplicationData. (Хранилище для каждой машины, потому что оно отражает изменения конфигурации в радиоустройствах, соединенных с ПК.) Мой установщик помечен в манифесте как администратор и создает подкаталоги со следующей подпрограммой:

private static void CreateAndPermit(SecurityIdentifier securityIdentifier, String path)
{
    DirectoryInfo info = new DirectoryInfo(path);
    if (!info.Exists)
        info.Create();

    DirectorySecurity security = info.GetAccessControl();
    AccessRule rule = new FileSystemAccessRule(securityIdentifier,
            FileSystemRights.Write |
            FileSystemRights.ReadAndExecute |
            FileSystemRights.Modify |
            FileSystemRights.CreateFiles,
            InheritanceFlags.ContainerInherit | InheritanceFlags.ObjectInherit,
            PropagationFlags.InheritOnly,
            AccessControlType.Allow);
    bool modified;
    security.ModifyAccessRule(AccessControlModification.Add, rule, out modified);
    info.SetAccessControl(security);
}

Это создает каталог, к которому пользователи рабочего стола могут обращаться с помощью Проводника, и где мое приложение может записывать данные конфигурации. Затем мой код приложения пытается обновить файл конфигурации в следующей последовательности (не используя File.Replace, поскольку я разбил шаги для отладки):

    if (File.Exists(filename + ".bak"))
        File.Delete(filename + ".bak");
    if (File.Exists(filename))
        File.Move(filename, filename + ".bak");
    File.Move(tmpfile, filename);

Этот код периодически (и никогда на моем компьютере разработки) выдает System.UnauthorizedAccessException, как правило, на этапе, где он удаляет файл резервной копии. После исключения проводник указывает, что «Все» имеет разрешения для всего, кроме «Специальные разрешения».

Единственная подсказка, с которой я столкнулся, заключается в том, что один конечный пользователь столкнулся с проблемой после переключения своего компьютера с XP Pro с автономного входа в систему с использованием домена.

1 Ответ

0 голосов
/ 25 марта 2011

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

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

Предположим, что произошел сбой, поймайте IOException и скажите пользователю, что он не будет работать прямо сейчас. ИТ-персонал пользователя знает, как, скажем, утилита SysInternals 'Handle, чтобы узнать, у кого файл заблокирован.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...