Pergunta

Suponha UAC é ON. Isso não cria um problema com ele desligado.

Eu tenho um aplicativo c # com um backup / restauração funcionalidade e usando o sql server 2005 express.

código para obter o backuppath é usado para backup e restaurar e o nome para todos os efeitos será backup.dat

para gerar caminho de backup

string path = Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData);
 path = Path.Combine(path, "CompName");
 if(!Directory.Exists(path))
        Directory.CreateDirectory(path);
 path = Path.Combine(path, "AppName");
 if(!Directory.Exists(path))
        Directory.CreateDirectory(path);
 return path;

no apoio a db gera backup.dat em ** C: \ ProgramData. \ CompName \ AppName ** e não tem nenhuma dificuldade em fechar a partir desse local a um diretório de destino da escolha usuários

Na restauração não tem nenhum problema para fazer o diretório arquivado ou o arquivo, mas quando se descomprime ele vai para ** C: \ Users \ nome do usuário \ AppData \ Local \ VirtualStore \ ProgramData \ CompName \ AppName **

Eu preciso saber por que o meu arquivo descompactado está indo para uma loja virtual para que eu possa restaurar a db porque pelo que eu entendo de programação para servidor vista sql não deve / não será capaz de acessar esse caminho loja virtual.

edit:. Falhou em fornecer com descompressão - Eu não acho que este é o problema, mas aqui está

private void DecompressArchiveFile(string compressedFile, string backupPath)
{
    GZipStream gzip = new GZipStream(new FileStream(compressedFile, FileMode.Open, FileAccess.Read, FileShare.None), CompressionMode.Decompress, false);
    FileStream fs = new FileStream(backupPath, FileMode.Create, FileAccess.Write, FileShare.None);

    byte[] buffer = new byte[10000];
    int count = -1;
    while (count != 0)
    {
        count = gzip.Read(buffer, 0, 10000);
        fs.Write(buffer, 0, count);
    }
    gzip.Close();
    fs.Close();
}

Obrigado por toda e qualquer ajuda -Tk

Foi útil?

Solução

Veja este Stack Overflow questão relacionada , em particular a partir do link a partir desta resposta :

FOLDERID_ProgramData / System.Environment.SpecialFolder.CommonApplicationData

O usuário nunca iria querer browse Aqui no Explorer e configurações alteradas aqui deve afetar todos os usuários do máquina. O local padrão é % Unidade_do_sistema% \ ProgramData, que é um escondido pasta, em uma instalação do Windows Vista. Você vai querer criar seu diretório e definir as ACLs você necessidade no momento da instalação.

Então, se você pretende seus usuários para ser capaz de escrever para esta pasta você terá que dar-lhes acesso adequado ao seu instalador é executado.

Se eles têm acesso de gravação para a pasta, em seguida, eu não acho que você vai correr em problemas com a virutalisation. No entanto, você deve realmente marcar a sua aplicação com o nível de privilégio exige adicionando algo como isto ao seu manifesto ( detalhes ):

<security>
  <requestedPrivileges>
    <requestedExecutionLevel level="asInvoker" />
  </requestedPrivileges>
</security>

Isso irá desativar a virtualização para o seu processo. Você pode ver se o seu processo está sendo virtualizado adicionando a coluna "A virtualização" para o Gerenciador de Tarefas sob View - Selecionar colunas ...

Aliás, Directory.CreateDirectory () irá criar diretórios pai automaticamente.

Outras dicas

Eu acho que você está batendo o recurso Vista Virtualização -. Que se destina a manter antigos aplicativos mal comportados de não funciona no Vista, onde eles não estão autorizados a escrever para% ProgramData%

O aplicativo pode ler a partir de% ProgramData%, mas não escrever para ele. Se você realmente quer escrever em% ProgramData% você tem que correr elevados (ou alterar a DACL no subpath para deixá-lo escrever).

http://technet.microsoft.com/en-us/ revista / cc160980.aspx (Data redirecionamento) para mais detalhes.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top