c # - Intermittent UautoriseretAccessException lagring konfigurationsfiler i CommonApplicationData

Indlæg af Hanne Mølgaard Plasc

Problem



Jeg har bygget en applikation, der har en lokal konfigurations butik under Environment.SpecialFolder.CommonApplicationData. (Butikken er per maskin, fordi den afspejler konfigurationsændringer i radioenheder, der er parret med pc'en.) Mit installationsprogram er markeret i manifestet til at køre som administrator og opretter underkataloger med følgende rutine:


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);
}


Dette skaber en mappe, som stationære brugere kan få adgang til ved hjælp af Explorer, og hvor min applikation kan skrive konfigurationsdata. Min ansøgningskode forsøger derefter at opdatere konfigurationsfilen med følgende rækkefølge (bruger ikke File.Replace, da jeg har brugt trinene til fejlfinding):


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


Denne kode intermitterende (og aldrig på min udviklingsmaskine) kaster System.UnauthorizedAccessException, generelt på det trin, hvor den sletter backupfilen. Efter undtagelsen angiver Explorer, at 'Alle' har tilladelser til alt undtagen 'Særlige tilladelser'.


Den eneste ledtråd, jeg har haft, er, at den ene slutbruger oplevede problemet, efter at have skiftet deres XP Pro-maskine fra standalone login til brug af et domæne.

Bedste reference


Sådanne er farerne ved at køre kode på et multi-tasking operativsystem, der er ingen garanti for, at en fil, du åbner eller bruger ikke er i brug ved en anden proces. Tænk søg indeksere, virus scannere, værktøjslinjer. Eller blot en anden proces, som brugeren begyndte at se på filen. Herunder en anden forekomst af dit program.


Hvis man antager, at sådanne programmer er uinteresserede i .bak-filer, er et scenario, hvor sletning af .bak-filen, der ikke er blevet arbejdet, på den anden -tid, brugeren gemmer filen. Hvor en anden proces havde et håndtag åbent på original fil. Omdøber filen til .bak bliver ikke et problem. Sletter det vil.


Antag fejl, tag IOException og fortæl brugeren, at den ikke vil arbejde lige nu. Brugerens IT-medarbejdere ved, hvordan man bruger, siger SysInternals 'Håndter værktøj for at finde ud af, hvem der har låst filen.