Armazenamento isolado
Para aplicativos de desktop, o armazenamento isolado é um mecanismo de armazenamento de dados que fornece isolamento e segurança, definindo maneiras padronizadas de associar código a dados salvos. A padronização também proporciona outros benefícios. Os administradores podem usar ferramentas projetadas para manipular o armazenamento isolado para configurar o espaço de armazenamento de arquivos, definir políticas de segurança e excluir dados não utilizados. Com o armazenamento isolado, seu código não precisa mais de caminhos exclusivos para especificar locais seguros no sistema de arquivos e os dados são protegidos de outros aplicativos que só têm acesso ao armazenamento isolado. Informações codificadas que indicam onde a área de armazenamento de um aplicativo está localizada são desnecessárias.
Importante
O armazenamento isolado não está disponível para aplicações da Loja Windows 8.x. Em vez disso, use as classes de dados do aplicativo nos Windows.Storage
namespaces incluídos na API do Tempo de Execução do Windows para armazenar dados e arquivos locais. Para obter mais informações, consulte Dados de aplicativos no Centro de Desenvolvimento do Windows.
Compartimentos e Armazenamentos de Dados
Quando um aplicativo armazena dados em um arquivo, o nome do arquivo e o local de armazenamento devem ser cuidadosamente escolhidos para minimizar a possibilidade de que o local de armazenamento seja conhecido por outro aplicativo e, portanto, vulnerável à corrupção. Sem um sistema padrão para gerenciar esses problemas, técnicas de improvisação que minimizam os conflitos de armazenamento podem ser complexas e os resultados podem não ser confiáveis.
Com o armazenamento isolado, os dados são sempre isolados por usuário e por montagem. Credenciais como a origem ou o nome forte do assembly determinam a identidade do assembly. Os dados também podem ser isolados por domínio do aplicativo, usando credenciais semelhantes.
Quando você usa armazenamento isolado, seu aplicativo salva dados em um compartimento de dados exclusivo que está associado a algum aspeto da identidade do código, como seu editor ou assinatura. O compartimento de dados é uma abstração, não um local de armazenamento específico; Ele consiste em um ou mais arquivos de armazenamento isolados, chamados armazenamentos, que contêm os locais de diretório reais onde os dados são armazenados. Por exemplo, um aplicativo pode ter um compartimento de dados associado a ele, e um diretório no sistema de arquivos implementaria o armazenamento que realmente preserva os dados para esse aplicativo. Os dados salvos na loja podem ser qualquer tipo de dados, desde informações de preferência do usuário até o estado do aplicativo. Para o desenvolvedor, a localização do compartimento de dados é transparente. As lojas geralmente residem no cliente, mas um aplicativo de servidor pode usar armazenamentos isolados para armazenar informações, representando o usuário em nome do qual está funcionando. O armazenamento isolado também pode armazenar informações em um servidor com o perfil móvel de um usuário para que as informações viajem com o usuário móvel.
Quotas para armazenagem isolada
Uma quota é um limite para a quantidade de armazenamento isolado que pode ser utilizado. A cota inclui bytes de espaço de arquivo, bem como a sobrecarga associada ao diretório e outras informações no armazenamento. O armazenamento isolado usa cotas de permissão, que são limites de armazenamento definidos usando IsolatedStoragePermission objetos. Se você tentar gravar dados que excedam a cota, uma IsolatedStorageException exceção será lançada. A diretiva de segurança, que pode ser modificada usando a Ferramenta de Configuração do .NET Framework (Mscorcfg.msc), determina quais permissões são concedidas ao código. O código que foi concedido IsolatedStoragePermission está restrito a não usar mais armazenamento do que o UserQuota permitido pela propriedade. No entanto, como o código pode ignorar as cotas de permissão apresentando identidades de usuário diferentes, as cotas de permissão servem como diretrizes para como o código deve se comportar, em vez de como um limite firme no comportamento do código.
As quotas não são aplicadas às lojas de itinerância. Devido a isso, um nível um pouco maior de permissão é necessário para o código usá-los. Os valores AssemblyIsolationByRoamingUser de enumeração e DomainIsolationByRoamingUser especificar uma permissão para usar armazenamento isolado para um usuário móvel.
Acesso Seguro
O uso de armazenamento isolado permite que aplicativos parcialmente confiáveis armazenem dados de maneira controlada pela diretiva de segurança do computador. Isso é especialmente útil para componentes baixados que um usuário pode querer executar com cautela. A política de segurança raramente concede esse tipo de permissão de código quando você acessa o sistema de arquivos usando mecanismos de E/S padrão. No entanto, por padrão, o código executado a partir do computador local, de uma rede local ou da Internet recebe o direito de usar armazenamento isolado.
Os administradores podem limitar a quantidade de armazenamento isolado que um aplicativo ou usuário tem disponível, com base em um nível de confiança apropriado. Além disso, os administradores podem remover completamente os dados persistentes de um usuário. Para criar ou acessar armazenamento isolado, o código deve receber a permissão apropriada IsolatedStorageFilePermission .
Para acessar o armazenamento isolado, o código deve ter todos os direitos de sistema operacional de plataforma nativos necessários. As listas de controle de acesso (ACLs) que controlam quais usuários têm os direitos de usar o sistema de arquivos devem ser satisfeitas. Os aplicativos .NET já têm direitos de sistema operacional para acessar o armazenamento isolado, a menos que executem representação (específica da plataforma). Nesse caso, o aplicativo é responsável por garantir que a identidade de usuário representada tenha os direitos de sistema operacional adequados para acessar o armazenamento isolado. Esse acesso fornece uma maneira conveniente para o código que é executado ou baixado da Web para ler e gravar em uma área de armazenamento relacionada a um usuário específico.
Para controlar o acesso ao armazenamento isolado, o common language runtime usa IsolatedStorageFilePermission objetos. Cada objeto tem propriedades que especificam os seguintes valores:
Uso permitido, que indica o tipo de acesso permitido. Os valores são membros da IsolatedStorageContainment enumeração. Para obter mais informações sobre esses valores, consulte a tabela na próxima seção.
Cota de armazenamento, conforme discutido na seção anterior.
O tempo de execução exige permissão quando o código tenta IsolatedStorageFilePermission abrir uma loja pela primeira vez. Ele decide se concede essa permissão, com base em quanto o código é confiável. Se a permissão for concedida, os valores de cota de uso e armazenamento permitidos serão determinados pela política de segurança e pela solicitação do código para IsolatedStorageFilePermission. A diretiva de segurança é definida usando a Ferramenta de Configuração do .NET Framework (Mscorcfg.msc). Todos os chamadores na pilha de chamadas são verificados para garantir que cada chamador tenha pelo menos o uso permitido apropriado. O tempo de execução também verifica a cota imposta ao código que abriu ou criou o repositório no qual o arquivo deve ser salvo. Se estas condições forem satisfeitas, a autorização é concedida. A cota é verificada novamente sempre que um arquivo é gravado no armazenamento.
O código do aplicativo não é necessário para solicitar permissão porque o Common Language Runtime concederá o que IsolatedStorageFilePermission for apropriado com base na política de segurança. No entanto, há boas razões para solicitar permissões específicas de que seu aplicativo precisa, incluindo IsolatedStorageFilePermission.
Uso permitido e riscos de segurança
O uso permitido especificado por IsolatedStorageFilePermission determina o grau em que o código terá permissão para criar e usar armazenamento isolado. A tabela a seguir mostra como o uso permitido especificado na permissão corresponde aos tipos de isolamento e resume os riscos de segurança associados a cada uso permitido.
Utilização permitida | Tipos de isolamento | Impacto na segurança |
---|---|---|
None | Não é permitido o uso isolado de armazenamento. | Não há impacto na segurança. |
DomainIsolationByUser | Isolamento por usuário, domínio e assembly. Cada assembly tem um subarmazenamento separado dentro do domínio. As lojas que usam essa permissão também são implicitamente isoladas pelo computador. | Esse nível de permissão deixa os recursos abertos ao uso excessivo não autorizado, embora as cotas impostas dificultem isso. Isso é chamado de ataque de negação de serviço. |
DomainIsolationByRoamingUser | O mesmo DomainIsolationByUser que , mas o armazenamento é salvo em um local que será roaming se os perfis de usuário móvel estiverem habilitados e as cotas não forem impostas. |
Como as cotas devem ser desabilitadas, os recursos de armazenamento ficam mais vulneráveis a um ataque de negação de serviço. |
AssemblyIsolationByUser | Isolamento por usuário e montagem. As lojas que usam essa permissão também são implicitamente isoladas pelo computador. | As quotas são aplicadas a este nível para ajudar a evitar um ataque de negação de serviço. O mesmo assembly em outro domínio pode acessar essa loja, abrindo a possibilidade de que informações possam ser vazadas entre aplicativos. |
AssemblyIsolationByRoamingUser | O mesmo AssemblyIsolationByUser que , mas o armazenamento é salvo em um local que será roaming se os perfis de usuário móvel estiverem habilitados e as cotas não forem impostas. |
Tal como na AssemblyIsolationByUser , mas sem quotas, o risco de um ataque de negação de serviço aumenta. |
AdministerIsolatedStorageByUser | Isolamento por utilizador. Normalmente, apenas ferramentas administrativas ou de depuração usam esse nível de permissão. | O acesso com essa permissão permite que o código visualize ou exclua qualquer um dos arquivos ou diretórios de armazenamento isolados de um usuário (independentemente do isolamento do assembly). Os riscos incluem, mas não estão limitados a, vazamento de informações e perda de dados. |
UnrestrictedIsolatedStorage | Isolamento por todos os usuários, domínios e assemblies. Normalmente, apenas ferramentas administrativas ou de depuração usam esse nível de permissão. | Essa permissão cria o potencial para um comprometimento total de todos os armazenamentos isolados para todos os usuários. |
Segurança de componentes de armazenamento isolados em relação a dados não confiáveis
Esta secção aplica-se aos seguintes enquadramentos:
- .NET Framework (todas as versões)
- .NET Core 2.1+
- .NET 5+
O .NET Framework e o .NET Core oferecem armazenamento isolado como um mecanismo para persistir dados para um usuário, um aplicativo ou um componente. Este é um componente herdado projetado principalmente para cenários de Segurança de Acesso ao Código agora obsoletos.
Várias APIs e ferramentas de armazenamento isolado podem ser usadas para ler dados além dos limites de confiança. Por exemplo, a leitura de dados de um escopo em toda a máquina pode agregar dados de outras contas de usuário, possivelmente menos confiáveis na máquina. Os componentes ou aplicativos que leem escopos de armazenamento isolados em toda a máquina devem estar cientes das consequências da leitura desses dados.
APIs sensíveis à segurança que podem ler a partir do escopo de toda a máquina
Os componentes ou aplicativos que chamam qualquer uma das seguintes APIs são lidos no escopo de toda a máquina:
- IsolatedStorageFile.GetEnumerator, passando um escopo que inclui o sinalizador IsolatedStorageScope.Machine
- IsolatedStorageFile.GetMachineStoreForApplication
- IsolatedStorageFile.GetMachineStoreForAssembly
- IsolatedStorageFile.GetMachineStoreForDomain
- IsolatedStorageFile.GetStore, passando um escopo que inclui o sinalizador IsolatedStorageScope.Machine
- IsolatedStorageFile.Remove, passando um escopo que inclui o
IsolatedStorageScope.Machine
sinalizador
A ferramenta storeadm.exe
de armazenamento isolada é afetada se chamada com o /machine
switch, conforme mostrado no código a seguir:
storeadm.exe /machine [any-other-switches]
A ferramenta de armazenamento isolado é fornecida como parte do Visual Studio e do SDK do .NET Framework.
Se o aplicativo não envolver chamadas para as APIs anteriores ou se o fluxo de trabalho não envolver chamadas storeadm.exe
dessa maneira, este documento não se aplica.
Impacto em ambientes multiutilizador
Como mencionado anteriormente, o impacto na segurança dessas APIs resulta de dados gravados de um ambiente de confiança lidos de um ambiente de confiança diferente. O armazenamento isolado geralmente usa um dos três locais para ler e gravar dados:
%LOCALAPPDATA%\IsolatedStorage\
: Por exemplo,C:\Users\<username>\AppData\Local\IsolatedStorage\
, paraUser
o âmbito.%APPDATA%\IsolatedStorage\
: Por exemplo,C:\Users\<username>\AppData\Roaming\IsolatedStorage\
, paraUser|Roaming
o âmbito.%PROGRAMDATA%\IsolatedStorage\
: Por exemplo,C:\ProgramData\IsolatedStorage\
, paraMachine
o âmbito.
Os dois primeiros locais são isolados por usuário. O Windows garante que diferentes contas de usuário na mesma máquina não possam acessar as pastas de perfil de usuário umas das outras. Duas contas de usuário diferentes que usam o ou User|Roaming
armazenam User
não verão os dados um do outro e não poderão interferir nos dados um do outro.
O terceiro local é compartilhado em todas as contas de usuário na máquina. Contas diferentes podem ler e gravar nesse local, e podem ver os dados uns dos outros.
Os caminhos anteriores podem diferir com base na versão do Windows em uso.
Agora considere um sistema multiusuário com dois usuários registrados Mallory e Bob. Mallory tem a capacidade de acessar seu diretório de C:\Users\Mallory\
perfil de usuário, e ela pode acessar o local C:\ProgramData\IsolatedStorage\
de armazenamento compartilhado em toda a máquina. Ela não pode acessar o diretório C:\Users\Bob\
de perfil de usuário do Bob.
Se Mallory quiser atacar Bob, ela pode escrever dados no local de armazenamento em toda a máquina e, em seguida, tentar influenciar Bob a ler a partir da loja em toda a máquina. Quando Bob executa um aplicativo que lê a partir desta loja, esse aplicativo irá operar nos dados Mallory colocados lá, mas a partir do contexto da conta de usuário de Bob. O restante deste documento contempla vários vetores de ataque e quais etapas os aplicativos podem fazer para minimizar o risco desses ataques.
Nota
Para que tal ataque ocorra, Mallory exige:
- Uma conta de usuário na máquina.
- A capacidade de colocar um arquivo em um local conhecido no sistema de arquivos.
- Conhecimento de que Bob em algum momento executará um aplicativo que tenta ler esses dados.
Estes não são vetores de ameaça que se aplicam a ambientes de desktop padrão de usuário único, como PCs domésticos ou estações de trabalho corporativas de um único funcionário.
Elevação de privilégios
Um ataque de elevação de privilégio ocorre quando o aplicativo de Bob lê o arquivo de Mallory e tenta automaticamente tomar alguma ação com base no conteúdo dessa carga. Considere um aplicativo que lê o conteúdo de um script de inicialização do repositório de toda a máquina e passa esse conteúdo para Process.Start
o . Se Mallory puder colocar um script mal-intencionado dentro da loja em toda a máquina, quando Bob iniciar seu aplicativo:
- Seu aplicativo analisa e lança o script malicioso de Mallory sob o contexto do perfil de usuário de Bob.
- Mallory ganha acesso à conta de Bob na máquina local.
Denial-of-service
Um ataque de negação de serviço ocorre quando o aplicativo de Bob lê o arquivo de Mallory e falha ou para de funcionar corretamente. Considere novamente o aplicativo mencionado anteriormente, que tenta analisar um script de inicialização do repositório de toda a máquina. Se Mallory puder colocar um arquivo com conteúdo malformado dentro do armazenamento em toda a máquina, ela poderá:
- Faça com que o aplicativo do Bob lance uma exceção no início do caminho de inicialização.
- Impedir que o aplicativo seja iniciado com êxito devido à exceção.
Ela então negou a Bob a capacidade de iniciar o aplicativo em sua própria conta de usuário.
Divulgação de informações
Um ataque de divulgação de informações ocorre quando Mallory pode enganar Bob para divulgar o conteúdo de um arquivo ao qual Mallory normalmente não tem acesso. Considere que Bob tem um arquivo secreto C:\Users\Bob\secret.txt que Mallory quer ler. Ela sabe o caminho para esse arquivo, mas não pode lê-lo porque o Windows a proíbe de obter acesso ao diretório de perfil de usuário de Bob.
Em vez disso, Mallory coloca um link rígido na loja de toda a máquina. Este é um tipo especial de arquivo que em si não contém nenhum conteúdo, em vez disso, ele aponta para outro arquivo no disco. Em vez disso, a tentativa de ler o arquivo de link físico lerá o conteúdo do arquivo direcionado pelo link. Depois de criar o link físico, Mallory ainda não consegue ler o conteúdo do arquivo porque ela não tem acesso ao destino (C:\Users\Bob\secret.txt
) do link. No entanto, Bob tem acesso a este arquivo.
Quando o aplicativo de Bob lê a partir da loja de toda a máquina, ele agora inadvertidamente lê o conteúdo de seu secret.txt
arquivo, como se o próprio arquivo estivesse presente na loja de toda a máquina. Quando o aplicativo de Bob é encerrado, se ele tentar salvar novamente o arquivo no armazenamento de toda a máquina, ele acabará colocando uma cópia real do arquivo no diretório *C:\ProgramData\IsolatedStorage*. Como esse diretório é legível por qualquer usuário na máquina, Mallory agora pode ler o conteúdo do arquivo.
Melhores práticas para se defender contra esses ataques
Importante: Se o seu ambiente tiver vários usuários mutuamente não confiáveis, não chame a API IsolatedStorageFile.GetEnumerator(IsolatedStorageScope.Machine)
ou invoque a ferramenta storeadm.exe /machine /list
. Ambos pressupõem que estão operando com base em dados confiáveis. Se um invasor puder semear uma carga mal-intencionada no armazenamento em toda a máquina, essa carga poderá levar a um ataque de elevação de privilégio no contexto do usuário que executa esses comandos.
Se estiver operando em um ambiente multiusuário, reconsidere o uso de recursos de armazenamento isolados destinados ao escopo da máquina . Se um aplicativo precisar ler dados de um local em toda a máquina, prefira ler os dados de um local que possa ser gravado apenas por contas de administrador. O %PROGRAMFILES%
diretório e o HKLM
hive do registro são exemplos de locais que podem ser gravados apenas por administradores e legíveis por todos. Os dados lidos a partir desses locais são, portanto, considerados confiáveis.
Se um aplicativo precisar usar o escopo Máquina em um ambiente multiusuário, valide o conteúdo de qualquer arquivo que você ler do repositório de toda a máquina. Se o aplicativo desserializar gráficos de objeto desses arquivos, considere usar serializadores mais seguros como XmlSerializer
em vez de serializadores perigosos como BinaryFormatter
ou NetDataContractSerializer
. Tenha cuidado com gráficos de objetos profundamente aninhados ou gráficos de objetos que executam a alocação de recursos com base no conteúdo do arquivo.
Locais de armazenamento isolados
Às vezes, é útil verificar uma alteração no armazenamento isolado usando o sistema de arquivos do sistema operacional. Você também pode querer saber a localização de arquivos de armazenamento isolados. Esse local é diferente dependendo do sistema operacional. A tabela a seguir mostra os locais raiz onde o armazenamento isolado é criado em alguns sistemas operacionais comuns. Procure diretórios Microsoft\IsolatedStorage neste local raiz. Você deve alterar as configurações da pasta para mostrar arquivos e pastas ocultos para ver o armazenamento isolado no sistema de arquivos.
Sistema operativo | Localização no sistema de arquivos |
---|---|
Windows 2000, Windows XP, Windows Server 2003 (atualização do Windows NT 4.0) | Lojas habilitadas para roaming = <SYSTEMROOT>\Perfis\<usuário>\Dados do aplicativo Lojas sem roaming = <SYSTEMROOT>\Perfis\<usuário>\Configurações Locais\Dados do Aplicativo |
Windows 2000 - instalação limpa (e atualizações do Windows 98 e Windows NT 3.51) | Lojas habilitadas para roaming = <SYSTEMDRIVE>\Documents and Settings\<user>\Application Data Lojas sem roaming = <SYSTEMDRIVE>\Documents and Settings\<user>\Local Settings\Application Data |
Windows XP, Windows Server 2003 - instalação limpa (e atualizações do Windows 2000 e Windows 98) | Lojas habilitadas para roaming = <SYSTEMDRIVE>\Documents and Settings\<user>\Application Data Lojas sem roaming = <SYSTEMDRIVE>\Documents and Settings\<user>\Local Settings\Application Data |
Windows 8, Windows 7, Windows Server 2008, Windows Vista | Lojas habilitadas para roaming = <SYSTEMDRIVE>\Usuários\<usuário>\AppData\Roaming Lojas sem roaming = <SYSTEMDRIVE>\Usuários\<usuário>\AppData\Local |
Criando, enumerando e excluindo armazenamento isolado
O .NET fornece três classes no System.IO.IsolatedStorage namespace para ajudá-lo a executar tarefas que envolvem armazenamento isolado:
IsolatedStorageFile, deriva e System.IO.IsolatedStorage.IsolatedStorage fornece gerenciamento básico de arquivos de assembly e aplicativos armazenados. Uma instância da IsolatedStorageFile classe representa um único armazenamento localizado no sistema de arquivos.
IsolatedStorageFileStream deriva e System.IO.FileStream fornece acesso aos arquivos em um armazenamento.
IsolatedStorageScope é uma enumeração que permite criar e selecionar um repositório com o tipo de isolamento apropriado.
As classes de armazenamento isolado permitem criar, enumerar e excluir armazenamento isolado. Os métodos para executar essas tarefas estão disponíveis através do IsolatedStorageFile objeto. Algumas operações exigem que você tenha a IsolatedStorageFilePermission permissão que representa o direito de administrar o armazenamento isolado, você também pode precisar ter direitos de sistema operacional para acessar o arquivo ou diretório.
Para obter uma série de exemplos que demonstram tarefas comuns de armazenamento isolado, consulte os tópicos de instruções listados em Tópicos relacionados.
Cenários para armazenamento isolado
O armazenamento isolado é útil em muitas situações, incluindo estes quatro cenários:
Controles baixados. Os controles de código gerenciado baixados da Internet não têm permissão para gravar no disco rígido por meio de classes de E/S normais, mas podem usar armazenamento isolado para manter as configurações dos usuários e os estados do aplicativo.
Armazenamento de componentes compartilhados. Os componentes compartilhados entre aplicativos podem usar armazenamento isolado para fornecer acesso controlado a armazenamentos de dados.
Armazenamento do servidor. Os aplicativos de servidor podem usar armazenamento isolado para fornecer armazenamentos individuais para um grande número de usuários que fazem solicitações ao aplicativo. Como o armazenamento isolado é sempre segregado por usuário, o servidor deve representar o usuário que faz a solicitação. Nesse caso, os dados são isolados com base na identidade do principal, que é a mesma identidade que o aplicativo usa para distinguir entre seus usuários.
Roaming. Os aplicativos também podem usar armazenamento isolado com perfis de usuário móvel. Isso permite que as lojas isoladas de um usuário circulem com o perfil.
Não utilize armazenamento isolado nas seguintes situações:
Para armazenar segredos de alto valor, como chaves ou senhas não criptografadas, porque o armazenamento isolado não é protegido contra código altamente confiável, código não gerenciado ou usuários confiáveis do computador.
Para armazenar código.
Para armazenar configurações e configurações de implantação, que os administradores controlam. (As preferências do usuário não são consideradas definições de configuração porque os administradores não as controlam.)
Muitos aplicativos usam um banco de dados para armazenar e isolar dados, caso em que uma ou mais linhas em um banco de dados podem representar armazenamento para um usuário específico. Você pode optar por usar armazenamento isolado em vez de um banco de dados quando o número de usuários for pequeno, quando a sobrecarga de usar um banco de dados for significativa ou quando não existir nenhum recurso de banco de dados. Além disso, quando o aplicativo requer um armazenamento mais flexível e complexo do que o fornecido por uma linha em um banco de dados, o armazenamento isolado pode fornecer uma alternativa viável.
Artigos relacionados
Title | Description |
---|---|
Tipos de isolamento | Descreve os diferentes tipos de isolamento. |
Como: Obter armazenamentos para armazenamento isolado | Fornece um exemplo de uso da IsolatedStorageFile classe para obter um armazenamento isolado por usuário e assembly. |
Como: enumerar armazenamentos para armazenamento isolado | Mostra como usar o IsolatedStorageFile.GetEnumerator método para calcular o tamanho de todo o armazenamento isolado para o usuário. |
Como: Excluir armazenamentos em armazenamento isolado | Mostra como usar o IsolatedStorageFile.Remove método de duas maneiras diferentes para excluir repositórios isolados. |
Como antecipar condições de falta de espaço com armazenamento isolado | Mostra como medir o espaço restante em um armazenamento isolado. |
Como: Criar arquivos e diretórios em armazenamento isolado | Fornece alguns exemplos de criação de arquivos e diretórios em um armazenamento isolado. |
Como: Localizar arquivos e diretórios existentes no armazenamento isolado | Demonstra como ler a estrutura de diretórios e arquivos em armazenamento isolado. |
Como: Ler e gravar em arquivos em armazenamento isolado | Fornece um exemplo de como gravar uma cadeia de caracteres em um arquivo de armazenamento isolado e lê-lo de volta. |
Como: Excluir arquivos e diretórios no armazenamento isolado | Demonstra como excluir arquivos de armazenamento isolados e diretórios. |
E/S de arquivo e fluxo | Explica como você pode executar acesso síncrono e assíncrono a arquivos e fluxos de dados. |