Conflitos e precedência
Ao incluir, excluir e redirecionar ficheiros e definições, é importante saber como a Ferramenta de Migração de Estado do Utilizador (USMT) lida com conflitos e precedência. Seguem-se os conflitos e diretrizes de precedência mais importantes a ter em conta ao trabalhar com o USMT.
Se existirem regras em conflito num componente, é aplicada a regra mais específica. No entanto, a <regra incondicionalExclude> é uma exceção porque tem precedência sobre todas as outras. Os nomes dos diretórios têm precedência sobre as extensões de ficheiro. Por exemplo, veja O que acontece quando existem regras de inclusão> e <exclusão> em conflito<? e o primeiro exemplo em <incluir> e <excluir> exemplos de precedência de regras mais à frente neste artigo.
Apenas as regras dentro do mesmo componente podem afetar-se mutuamente, consoante a especificidade. As regras que estão em componentes diferentes não se afetam mutuamente, exceto a <regra incondicionalExclude> .
Se as regras forem igualmente específicas, <a exclusão> tem precedência sobre <incluir>. Por exemplo, se a <regra de exclusão> for utilizada para excluir um ficheiro e utilizar a <regra de inclusão> para incluir o mesmo ficheiro, o ficheiro será excluído.
A ordenação dos componentes não importa. Não importa que componentes estão listados em que .xml ficheiro, porque cada componente é processado independentemente dos outros componentes em todos os ficheiros .xml .
A ordenação das regras de <inclusão> e <exclusão> num componente não importa.
O <elemento incondicionalExclude> pode ser utilizado para excluir dados globalmente. Este elemento exclui objetos, independentemente de quaisquer outras <regras de inclusão> que estejam nos ficheiros .xml . Por exemplo, o <elemento incondicionalExclude> pode ser utilizado para excluir todos os ficheiros MP3 no computador ou para excluir todos os ficheiros do
C:\UserData.
Geral
Qual é a relação entre regras localizadas em diferentes componentes?
Apenas as regras dentro do mesmo componente podem afetar-se mutuamente, consoante a especificidade, exceto a <regra incondicionalExclude> . As regras que estão em componentes diferentes não se afetam mutuamente. Se existir uma <regra de inclusão> num componente e uma regra de exclusão> idêntica< noutro componente, os dados são migrados porque as duas regras são independentes uma da outra.
Se uma <regra de inclusão> estiver num componente e uma <regra locationModify> estiver noutro componente para o mesmo ficheiro, o ficheiro será migrado em ambos os locais. Ou seja, o ficheiro é incluído com base na <regra de inclusão> e o ficheiro é migrado com base na <regra locationModify> .
O ficheiro .xml seguinte migra todos os ficheiros de C:\Userdocs, incluindo ficheiros.mp3 , porque a <regra de exclusão> é especificada num componente separado.
<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/UserDocs">
<component type="Documents" context="System">
<displayName>User Documents</displayName>
<role role="Data">
<rules>
<exclude>
<objectSet>
<pattern type="File">C:\Userdocs\* [*.mp3]</pattern>
</objectSet>
</exclude>
</rules>
</role>
</component>
<component type="Documents" context="System">
<displayName> User documents to include </displayName>
<role role="Data">
<rules>
<include>
<objectSet>
<pattern type="File"> C:\Userdocs\ [*]</pattern>
</objectSet>
</include>
</rules>
</role>
</component>
</migration>
Como funciona a precedência com o ficheiro Config.xml?
Especificar migrate="no" no Config.xml ficheiro é o mesmo que eliminar o componente correspondente do ficheiro de.xml de migração. No entanto, se migrate="no" estiver definida para a pasta Documentos , mas existir uma regra semelhante à seguinte regra num ficheiro de .xml de migração (que inclui todos os ficheiros .doc da pasta Documentos ), apenas os ficheiros .doc são migrados e todos os outros ficheiros são excluídos:
<include>
<objectSet>
<pattern type="File">%CSIDL_PERSONAL%\* [*.doc] </pattern>
</objectSet>
</include>
Como é que o USMT processa cada componente num ficheiro de .xml com vários componentes?
A ordenação dos componentes não importa. Cada componente é processado independentemente de outros componentes. Por exemplo, se uma <regra de inclusão> estiver num componente e uma <regra locationModify> estiver noutro componente para o mesmo ficheiro, o ficheiro será migrado em ambos os locais. Ou seja, o ficheiro é incluído com base na <regra de inclusão> e o ficheiro é migrado com base na <regra locationModify> .
Como são processadas as regras?
Existem duas amplas categorias de regras.
Regras que afetam o comportamento das ferramentas ScanState e LoadState. Por exemplo, as <regras include>, <exclude> e <incondicionalExclude> são processadas para cada componente nos ficheiros .xml . Para cada componente, o USMT cria uma lista de inclusão e uma lista de exclusão. Algumas das regras no componente podem ser eliminadas devido à especificidade, mas todas as restantes regras são processadas. Para cada <regra de inclusão> , o USMT itera através dos elementos para ver se alguma das localizações tem de ser excluída. O USMT enumera todos os objetos e cria uma lista de objetos que vai recolher para cada utilizador. Assim que a lista estiver concluída, cada um dos objetos é armazenado ou migrado para o computador de destino.
Regras que afetam o comportamento apenas da ferramenta LoadState. Por exemplo, as <regras locationModify>, <contentModify> e <destinationCleanup> não afetam ScanState. São processados apenas com LoadState. Em primeiro lugar, a ferramenta LoadState determina o conteúdo e a localização de cada componente com base nas <regras locationModify> e <contentModify> . Em seguida, LoadState processa todas as <regras destinationCleanup> e elimina dados do computador de destino. Por fim, LoadState aplica os componentes ao computador.
Como é que o USMT combina todos os ficheiros .xml que especifique na linha de comandos?
O USMT não distingue os ficheiros .xml com base no respetivo nome ou conteúdo. Processa cada componente nos ficheiros separadamente. O USMT suporta vários ficheiros de.xml apenas para facilitar a manutenção e a organização dos componentes dentro dos mesmos. Uma vez que o USMT utiliza um urlid para distinguir cada componente dos outros, certifique-se de que cada .xml ficheiro especificado na linha de comandos tem um urlid de migração exclusivo.
As <regras de inclusão> e <exclusão>
O que acontece quando existem regras de inclusão> e <exclusão> em <conflito?
Se existirem regras em conflito num componente, é aplicada a regra mais específica, exceto com a <regra incondicionalExclude> , que tem precedência sobre todas as outras regras. Se as regras forem igualmente específicas, os dados não serão migrados. Por exemplo, se o mesmo ficheiro estiver excluído e incluído, o ficheiro não será migrado. Se existirem regras em conflito dentro de diferentes componentes, as regras não se afetam umas às outras porque cada componente é processado de forma independente.
No exemplo seguinte, os ficheiros mp3 não são excluídos da migração. Os ficheiros mp3 não são excluídos porque os nomes dos diretórios têm precedência sobre as extensões de ficheiro.
<include>
<objectSet>
<pattern type="File">C:\Data\* [*]</pattern>
</objectSet>
</include>
<exclude>
<objectSet>
<pattern type="File"> C:\* [*.mp3]</pattern>
</objectSet>
</exclude>
<exemplos de precedência de inclusão> e <exclusão> de regras
Estes exemplos explicam como a USMT lida com <regras de inclusão> e <exclusão> . Quando as regras estão em componentes diferentes, o comportamento resultante é o mesmo, independentemente de os componentes estarem no mesmo ou em diferentes .xml ficheiros.
Incluir e excluir ficheiros
| Se o código seguinte existir no mesmo componente | Comportamento resultante | Explicação |
|---|---|---|
|
Migra todos os ficheiros e subpastas no Dir1 (incluindo todos os ficheiros .txt em C:). | A <regra de exclusão> não afeta a migração porque a <regra de inclusão> é mais específica. |
|
Migra todos os ficheiros e subpastas em C:\Dir1, exceto os ficheiros .txt em C:\Dir1\Dir2 e as respetivas subpastas. | Ambas as regras são processadas conforme pretendido. |
|
Migra todos os ficheiros e subpastas em C:\Dir1, exceto os ficheiros .txt em C:\Dir1 e as respetivas subpastas. | Ambas as regras são processadas conforme pretendido. |
|
Nada é migrado. | As regras são igualmente específicas, pelo que a <regra de exclusão> tem precedência sobre a <regra de inclusão> . |
|
Migra os ficheiros de.txt no Dir1 e os ficheiros .txt de subpastas que não o Dir2. Não são migrados ficheiros do Dir2 ou das respetivas subpastas. |
Ambas as regras são processadas conforme pretendido. |
|
Migra todos os ficheiros e subpastas do Dir2, exceto os ficheiros .txt do Dir1 e quaisquer subpastas do Dir1 (incluindo o Dir2). | Ambas as regras são processadas conforme pretendido. |
| Se o código seguinte existir em diferentes componentes | Comportamento resultante | Explicação |
|---|---|---|
Componente 1:
Componente 2:
|
Migra todos os ficheiros e subpastas de C:\Dir1\ (incluindo C:\Dir1\Dir2). | As regras que estão em componentes diferentes não se afetam mutuamente, exceto a <regra incondicionalExclude> . Por conseguinte, neste exemplo, apesar de alguns ficheiros.txt terem sido excluídos quando o Componente 1 foi processado, foram incluídos quando o Componente 2 foi processado. |
Componente 1:
Componente 2:
|
Migra todos os ficheiros e subpastas do Dir2, exceto os ficheiros .txt em C:\Dir1 e as respetivas subpastas. | Ambas as regras são processadas conforme pretendido. |
Componente 1:
Componente 2:
|
Migra todos os .txtficheiros no Dir1 e quaisquer subpastas. | O componente 1 não contém uma <regra de inclusão> , pelo que a <regra de exclusão> não é processada. |
Incluir e excluir objetos de registo
| Se o código seguinte existir no mesmo componente | Comportamento resultante | Explicação |
|---|---|---|
|
Migra todas as chaves em HKLM\Software\Microsoft\Command Processor, exceto DefaultColor. | Ambas as regras são processadas conforme pretendido. |
|
Migra apenas DefaultColor em HKLM\Software\Microsoft\Command Processor. | DefaultColor é migrado porque a <regra de inclusão> é mais específica do que a <regra de exclusão> . |
|
Não migra DefaultColor. | As regras são igualmente específicas, pelo que a <regra de exclusão> tem precedência sobre a <regra de inclusão> . |
| Se o código seguinte existir em diferentes componentes | Comportamento resultante | Explicação |
|---|---|---|
Componente 1:
Componente 2:
|
Migra todas as chaves/valores em HKLM\Software\Microsoft\Processador de Comandos. | As regras que estão em componentes diferentes não se afetam mutuamente, exceto a <regra incondicionalExclude> . Neste exemplo, os objetos que foram excluídos quando o Componente 1 foi processado foram incluídos quando o Componente 2 foi processado. |
Colisões de ficheiros
Qual é o comportamento predefinido quando existem colisões de ficheiros?
Se não existir uma <regra de intercalação> , o comportamento predefinido do registo é que a origem substitua o destino. O comportamento predefinido dos ficheiros é que o nome da origem seja alterado incrementalmente: por exemplo, OriginalFileName(1). OriginalExtension, OriginalFileName(2). OriginalExtension, etc.
Como funciona a <regra de intercalação> quando existem colisões de ficheiros?
Quando é detetada uma colisão, a USMT seleciona a regra de intercalação> mais específica< e aplica-a para resolve o conflito. Por exemplo, se existir uma<> regra de intercalação para C:\* [*] definida como sourcePriority()e outra<> regra de intercalação para C:\subpasta\* [*] definida como destinationPriority() , o USMT utiliza a regra destinationPriority() porque é a mais específica.
Cenário de exemplo
O computador de origem contém os seguintes ficheiros:
C:\Data\SampleA.txtC:\Data\SampleB.txtC:\Data\Folder\SampleB.txt
O computador de destino contém os seguintes ficheiros:
C:\Data\SampleB.txtC:\Data\SampleB.txt
Um ficheiro de.xml personalizado contém o seguinte código:
<include>
<objectSet>
<pattern type="File">c:\data\* [*]</pattern>
</objectSet>
</include>
Para este exemplo, as seguintes informações descrevem o comportamento resultante se o código for adicionado ao ficheiro de.xml personalizado.
Exemplo 1
<merge script="MigXmlHelper.DestinationPriority()">
<objectSet>
<pattern type="File">c:\data* []</pattern>
</objectSet>
</merge>
Resultado: durante o ScanState, todos os ficheiros são adicionados ao arquivo. Durante o LoadState, só C:\Data\SampleA.txt é restaurado.
Exemplo 2
<merge script="MigXmlHelper.SourcePriority()">
<objectSet>
<pattern type="File">c:\data* []</pattern>
</objectSet>
</merge>
Resultado: durante o ScanState, todos os ficheiros são adicionados ao arquivo. Durante o LoadState, todos os ficheiros são restaurados, substituindo os ficheiros existentes no computador de destino.
Exemplo 3
<merge script="MigXmlHelper.SourcePriority()">
<objectSet>
<pattern type="File">c:\data\ [*]</pattern>
</objectSet>
</merge>
Resultado: durante o ScanState, todos os ficheiros são adicionados ao arquivo. Durante o LoadState, ocorrem as seguintes ações:
-
C:\Data\SampleA.txté restaurado. -
C:\Data\SampleB.txté restaurado, substituindo o ficheiro existente no computador de destino. -
C:\Data\Folder\SampleB.txtnão são restaurados.