Os arquivos de fluxo VOS são limitados em crescimento a cerca de 2 GB. Isto porque a definição de interfaces como s$seq_position, s$get_port_status, s$lock_region, etc. usam variáveis de 32 bits assinadas para indicar posição no arquivo e 2**31 é o maior valor possível que pode ser representado. Em arquivos stream, a posição é byte-offset em vez de número de registro como em outras organizações de arquivos VOS.
Os arquivos de 64 bits estão disponíveis a partir do Release 17.2 e permitem o crescimento limitado apenas pelo sistema de arquivos VOS (o tamanho máximo de qualquer arquivo é de 512 GB). Além de expandir o potencial de crescimento, estes arquivos oferecem outras vantagens, particularmente quando se acessa dados binários. Ao contrário dos arquivos de fluxo normal, blocos contendo todos os zeros binários não ocupam espaço em disco, e a leitura de tais dados não requer acesso ao disco.
As aplicações compatíveis com Posix podem ser facilmente construídas para o conhecimento de grandes arquivos sem nenhuma mudança de fonte: novos arquivos criados em discos rodando em módulos 17.2+ serão arquivos de 64 bits (freqüentemente chamados de stream64) e em módulos pré-17.2 serão arquivos stream comuns. As aplicações que utilizam interface VOS s$ ou VOS Language I/O são chamadas aplicações nativas e aquelas que utilizam arquivos stream64 poderão acessar arquivos stream64 desde que não utilizem operações de posicionamento byte (o posicionamento para BOF ou EOF não é considerado posicionamento byte) OU se o arquivo for No entanto, eles precisarão ser modificados a fim de criar arquivos stream64.
Aqui estão algumas informações que podem ser úteis se/quando você planeja fazer uso de arquivos de 64 bits. Ela está organizada da seguinte forma:
Aplicações e Compatibilidade Existentes
- Aplicações Posix Existentes
- Aplicações Nativas Existentes
- Compatibilidade
- Produtos de código aberto
Alocação esparsa
Conversão de arquivos
Características físicas
- Extensões
- Como as Extensões Afetam a Alocação Esparsa
- Extensões Flexíveis
Ferramentas
- Localização de arquivos de fluxo de 64 bits em um módulo
- Comparação de blocos
- Comparação de arquivos esparsos
Aplicações e Compatibilidade Existentes
- Aplicações Posix Existentes
A partir do Release 17.2, as aplicações Posix podem ser construídas para a visualização de grandes arquivos, permitindo então acessar arquivos de 64 bits e criá-los se o alvo estiver em um disco rodando no 17.2 ou mais. Se a aplicação é compatível com Posix (por exemplo, é codificada para usar tipos como off_t ao invés de int quando necessário), então não são necessárias mudanças na fonte; simplesmente construa-a como descrito no manual de referência do OpenVOS POSIX.1, R502, "Porting Existing Applications to the 64-bit Stream File Environment". Se um arquivo sendo criado estiver em um disco em um módulo rodando pré-17.2, então um arquivo de fluxo normal é criado, e tudo estará bem com falha ocorrendo somente se for feita uma tentativa de crescimento do arquivo > 2 GB. Portanto, permitir que sua aplicação Posix utilize arquivos grandes não custa nada em termos de interoperabilidade. A maioria dos produtos de código aberto suportados por VOS produzirão e lidarão corretamente com arquivos de 64 bits a partir do Release 17.2.
As aplicações compatíveis com Posix podem ser facilmente construídas para o conhecimento de grandes arquivos sem nenhuma mudança de fonte: novos arquivos criados em discos rodando em módulos 17.2+ serão arquivos de 64 bits (muitas vezes chamados de stream64) e em módulos pré-17.2 serão arquivos de stream comuns. Aplicações que utilizam interface VOS s$ ou VOS Language I/O são chamadas aplicações nativas e aquelas que utilizam arquivos stream64 poderão acessar arquivos stream64 desde que não utilizem operações de posicionamento de bytes (o posicionamento para BOF ou EOF não é considerado posicionamento de bytes) OU se o arquivo for menor que 2 GB.
- Aplicações Nativas Existentes
Muitas aplicações nativas simplesmente precisam mudar o uso do comando create_file (ou s$create_file) para indicar que a organização é STREAM64 em vez de STREAM. Se a aplicação usa operações de posicionamento e o arquivo cresce para > 2 GB, então s$seq_position produzirá um erro: para suportar arquivos maiores, s$seq_position calls precisa ser alterado para s$seq_position_x. Novamente, o uso de interfaces _x não interfere na capacidade da aplicação de referenciar arquivos de fluxo normal existentes em módulos que podem não suportar as interfaces _x, desde que os argumentos posicionais estejam na faixa suportada. Portanto, fazer a mudança permite o acesso a qualquer tipo de arquivo de fluxo e não custa nada em interoperabilidade.
As aplicações existentes que utilizam apenas interfaces que não comunicam a posição do byte: s$seq_read, s$seq_write, s$seq_position BOF/EOF serão capazes de lidar com arquivos stream64 sem modificações. Muitas aplicações são escritas para lidar com arquivos ASCII, sejam eles seqüenciais ou stream e, portanto, não precisam de alteração para lidar com arquivos stream de 64 bits, independentemente do tamanho.
Os arquivos de 64 bits não podem ter índices, e assim um arquivo de fluxo indexado não pode ser convertido em fluxo64. Os arquivos de stream indexados não podem crescer até > 2 GB devido a restrições na implementação do índice existente.
- Compatibilidade
Como os arquivos de 64 bits oferecem uma série de vantagens, eles devem ser adotados quando possível, se não for necessário um índice.
Desde que o arquivo não cresça > 2 GB, ele pode ser copiado ou movido para módulos rodando versões mais antigas do VOS, e aparecerá lá como um arquivo de fluxo normal. Você pode até mesmo mover um disco contendo arquivos stream64 para um VOS mais antigo, desde que os arquivos não sejam "restritos". Um arquivo é restrito quando cresce > 2 GB ou é pouco alocado; tais arquivos não podem ser abertos se o disco que os contém for movido para um VOS pré-17.2 (ferramentas estão disponíveis para identificar arquivos restritos se você estiver planejando tal movimento). Entretanto, aplicativos rodando versões antigas do VOS podem abrir, ler e escrever qualquer tipo de arquivo stream64 através da rede; qualquer falha que ocorra é a mesma como se o aplicativo estivesse rodando em 17,2+ (por exemplo, uso de s$seq_position para posicionamento de bytes quando o arquivo exceder 2 GB).
- Produtos de código aberto
A maioria dos Softwares Abertos suportados no VOS foi convertida para ser um arquivo grande, por exemplo, ftp, sftp, samba, etc. Isso tem certas implicações. A partir da versão 17.2, você pode agora ftp um arquivo stream para VOS e não se preocupar com o tamanho do arquivo, já que o daemon ftp criará um arquivo stream64. ftp escreve todos os bytes e, portanto, o arquivo resultante não será esparso (veja próxima seção), mesmo que consista principalmente de zeros binários. A simples cópia do arquivo transferido pode reduzir muito o espaço em disco que ele ocupa. Se você planeja adicionar um índice ao arquivo ftp'ed, você deve primeiro convertê-lo para um arquivo de fluxo comum (e é claro que não deve exceder 2 GB de comprimento).
Alocação esparsa
Os blocos que contêm todos os zeros binários nem sempre são alocados para arquivos stream64 e, portanto, não necessitam de espaço em disco. O comando gnu "truncado" (em >system>gnu_library>bin) pode ser usado tanto para truncar quanto para ampliar o tamanho de um arquivo stream. No 18.0, o VOS fornece um comando similar chamado reset_eof. Dados anteriores a EOF são indefinidos, mas quando EOF é estendido, o conteúdo do arquivo a partir do ponto da EOF atual é sempre definido como zeros binários.
Considere um arquivo stream comum e um arquivo stream64:
create_file stm - fluxo de organização
create_file s64 - fluxo de organização64
e assumir que cada um tem conteúdo 'abc'. Desejamos ampliar os arquivos de modo que cada um ocupem 2 bilhões de bytes:
bash
bash-4,2$ truncado -s 2000000000 s64
bash-4,2$ truncado -s 2000000000 stm
A primeira solicitação termina imediatamente enquanto a segunda leva vários minutos. Os arquivos mostram uma equivalência lógica:
bash-4,2$ ls -l
total 244382
-rwxrwxrwx 1 nobody nobody 2000000000 Fev 25 14:08 s64
-rwxrwxrwxrwx 1 nobody nobody 2000000000 Fev 25 14:11 stm
Entretanto, o número de blocos de disco que cada arquivo ocupa é bem diferente, como mostra o comando da lista VOS:
lista
Arquivos: 2, Blocos: 488764
w 4 s64
w 488760 stm
No Release 18.0, as operações equivalentes podem usar o comando VOS reset_eof:
reset_eof s64 2000000000
O comando VOS advertirá se você pedir para estender um arquivo de fluxo comum por mais de alguns milhares de blocos, uma vez que esta é uma operação tão cara
reset_eof stm 2000000000
A ampliação do eof para 2000000000 adicionará 488281 blocos ao arquivo. Você deseja estender o stm até 199999999996 bytes? (sim, não)
Aqui está o arquivo do fluxo de 64 bits após ter sido estendido. Ele consiste de apenas dois blocos de dados:
dump_file s64
Bloco número 1
000 6162630A 00000000 00000000 00000000 00000000 |abc.............|
FF0 00000000 00000000 00000000 00000000 00000000 |................|
Bloco número 488282
000 00000000 00000000 00000000 00000000 |…………….|
FF0 00000000 00000000 00000000 00000000 00000000 |................|
Ao despejar o arquivo de fluxo comum stm, serão exibidos todos os 488282 blocos que foram alocados com a maioria dos blocos contendo zeros binários.
dump_file stm
Bloco número 1
000 6162630A 00000000 00000000 00000000 00000000 |abc.............|
FF0 00000000 00000000 00000000 00000000 00000000 |................|
Bloco número 2
000 00000000 00000000 00000000 00000000 |…………….|
FF0 00000000 00000000 00000000 00000000 00000000 |................|
Bloco número 3
…
Bloco número 488282
000 00000000 00000000 00000000 00000000 |…………….|
400 FFFFFFFFFF FFFFFFFFFF FFFFFFFFFF FFFFFFFFFF |................|
FF0 FFFFFFFF FFFFFFFFFF FFFFFFFFFF FFFFFFFF FFFFFFFF |................|
No entanto, compare_files e diff vêem os arquivos como equivalentes, mas precisam ler todos os blocos do arquivo de fluxo comum que, neste caso, pode demorar alguns minutos:
ready;compare_files s64 stm
pronto 14:29:47
pronto 14:31:24 45.877 46
Conversão de arquivos
O comando convert_stream_file está disponível para converter entre qualquer um dos tipos de arquivo sequencial e de fluxo (fluxo, fluxo de 64 bits, sequencial e sequencial estendido) e para alterar extensões. Normalmente, a conversão envolve a cópia do conteúdo do arquivo e desta forma é semelhante à criação de um arquivo de destino vazio e o uso do copy_file com a opção -truncate. convert_stream_file pode ser usado para alterar o arquivo no local e tem a vantagem de garantir que o conteúdo existente possa ser representado no novo formato solicitado antes de tentar a conversão.
There are cases where a stream file can be reset to stream64 and vice versa without conversion, i.e., without copying contents. This is done by resetting the directory entry and is possible only if the file is not sparse, is less that 2 GB and extent size is not changed. This can be useful when migrating a disk containing stream64 files to a pre-17.2 module and again if the disk is moved back. The set_stream_files command is available for this purpose. It is a privileged command intended for use by a System Administrator: it takes a directory as input and resets files in that directory, and optionally in all sub-directories. It affects only those stream64 files which can be reset without conversion (not sparse and otto>stm
file organization: stream file
last used at: 15-02-25 14:34:45 est
…
extent size: 1
next byte: 2000000000
blocks used: 488760 <<<<<
Então:
convert_stream_file stm -to stream64 -extent_size 8
display_file_status stm
file organization: stream file (64-bit/rstr)
last used at: 15-02-25 14:39:16 est
…
extent size: 8
next byte: 2000000000
blocks used: 18 <<<<
sparse: yes
O arquivo resultante é mostrado como restrito (64-bit/rstr) devido a ele ser agora esparso. O comando copy_file também produzirá um arquivo esparso. A conversão de um arquivo stream64 em um arquivo stream comum resultará em todos os blocos instanciados e assim o arquivo resultante poderá ser consideravelmente maior do que o original.
Em um arquivo stream64, não há garantia de que um bloco que por acaso contenha zeros binários seja ou não alocado em disco. Por exemplo, se você escrever alguns zeros em um bloco que então acaba sendo todos os zeros, o bloco permanece alocado - ou se um programa escrever explicitamente zero dados preenchendo blocos. Somente os blocos que nunca são escritos permanecem sem alocação; copiar_arquivo e converter_arquivo_stream nunca escrevem blocos contendo todos os zeros binários.
Características físicas
- Extensões
O limite real de crescimento de qualquer arquivo VOS é determinado por seu tamanho, portanto é importante entender o que é uma extensão. O mapa de arquivo VOS contém endereços de disco para cada bloco de 4k em um arquivo; ele é limitado a 523792 entradas e, portanto, qualquer arquivo sem extensões é limitado a 2145452032 (523792 * 4096) bytes. Isto é ligeiramente inferior a 2**31 e, portanto, é o limite real do crescimento de um arquivo de fluxo comum.
Uma extensão é um grupo de N blocos contíguos em disco, onde N é o tamanho da extensão. O mapa de arquivo para um arquivo alocado por extensões contém o endereço do primeiro bloco na extensão e, portanto, permite que o mapa de arquivo represente um arquivo significativamente maior. Os extensões alocadas dinamicamente permitem um tamanho de extensão de até 256 permitindo um arquivo contendo 512 GB (Nota: as extensões alocadas estaticamente que permitem um tamanho de extensão maior que 256 são depreciadas, exceto para uso com arquivos de paging; estes têm muitas restrições e problemas de desempenho que tornam então inaceitável para uso geral).
Para crescer além de 2 GB, um arquivo stream64 deve ter extensões, cujo valor determinará seu limite de crescimento real. Por exemplo, um arquivo de 64 GB,
create_file stm64 -organization steam64 -extent_size 32
criará um arquivo que pode crescer até 64 GB.
No lançamento 17.2, o tamanho padrão de extensão para arquivos criados pela Posix Runtime é 8, permitindo um crescimento de até 16 GB. Tais arquivos crescem 8 blocos de cada vez, e assim o tamanho mínimo de qualquer arquivo é de 8 blocos. Este padrão pode ser alterado por um Administrador de Sistema por módulo, mas quanto maior o potencial de crescimento, maior é o tamanho mínimo de um arquivo. Maiores extensões podem ser um problema para aplicações que produzem muitos arquivos muito pequenos.
- Como as Extensões Afetam a Alocação Esparsa
Normalmente blocos que nunca são escritos não são alocados para arquivos stream64; no entanto, se um bloco em uma extensão é escrito, então todos os blocos nessa extensão são alocados, mesmo que alguns contenham todos os zeros binários.
Suponha que um arquivo não-extenso contendo a cadeia abc (stm1) seja convertido em um arquivo com tamanho 8 (stm8):
dump_file stm1
Bloco número 1
000 6162630A 00000000 00000000 00000000 00000000 |abc.............|
010 00000000 00000000 00000000 00000000 |…………….|
FF0 00000000 00000000 00000000 00000000 00000000 |................|
convert_stream_file stm1 stm8 -extent_size 8
dump_file stm8
Bloco número 1
000 6162630A 00000000 00000000 00000000 00000000 |abc.............|
010 00000000 00000000 00000000 00000000 |…………….|
FF0 00000000 00000000 00000000 00000000 00000000 |................|
Bloco número 2
000 00000000 00000000 00000000 00000000 |…………….|
FF0 00000000 00000000 00000000 00000000 00000000 |................|
Bloco número 3
…
Bloco número 8
000 00000000 00000000 00000000 00000000 |…………….|
FF0 00000000 00000000 00000000 00000000 00000000 |................|
A opção -brief foi adicionada ao dump_file no release 18.0 e pode ser útil quando você não quer ver blocos que estão fisicamente presentes, mas representam blocos "vazios" (potencialmente inexistentes). O uso desta opção com o arquivo DAE-8 é mostrado abaixo:
dump_file stm8 -brief
Bloco número 1
000 6162630A 00000000 00000000 00000000 00000000 |abc.............|
010 00000000 00000000 00000000 00000000 |…………….|
FF0 00000000 00000000 00000000 00000000 00000000 |................|
Isto é eficaz também na ocultação de blocos "vazios" contendo todos os -1′s para parentes de arquivos fixos.
- Extensões Flexíveis
Extensões flexíveis foram introduzidas no Release 18.0 permitindo que um pequeno arquivo cresça um bloco de cada vez; à medida que o arquivo cresce, o valor da extensão muda. Este é o padrão para todos os arquivos criados pelos aplicativos Posix no Release 18.0 e é o que você obterá com o comando create_file se não der um tamanho de extensão específico:
create_file flex -organization stream64 -extent_size
Os arquivos com extensões flexíveis são chamados de arquivos flexíveis; somente os arquivos stream64 podem ter extensões flexíveis. O comando display_file_status mostra o tamanho de um arquivo flex como "flex".
display_file_status flex
nome: %swsle#Raid4>flex
organização do arquivo: arquivo stream (64 bits)
modificado pela última vez em: 15-02-25 12:06:25 est
…
extensões dinâmicas: sim
tamanho da extensão: flex
Se o comando display_file_status é executado em um módulo pré-18.0, ele mostra:
tamanho da extensão: -1
Se um arquivo flex é copiado para um disco em um módulo 17.2, ele tem extensões que são o padrão para esse módulo. Se copiado para 17.1 ou antes, o resultado é um arquivo de fluxo comum.
No release 17.2+, compare_files não vê diferenças de tamanho entre arquivos de fluxo, e os arquivos parecem idênticos, independentemente dos extensões. Por exemplo, suponha que a %swsle#m109_mas esteja em um módulo rodando 17.2:
copy_file flex %swsle#m109_mas>Stratus
compare_files flex %swsle#m109_mas>Stratus>flex
pronto 14:42:38 0.001 6
A execução do compare_files em um módulo pré-17.2 mostrará isto como uma diferença:
compare_files %swsle#Raid>flex %swsle#m109_mas>Stratus>flex
A (%swsle#Raid4>flex não corresponde a B (%swsle#m109_mas>Stratus>flex).
- Alguns atributos dos dois arquivos não combinam:
tamanho de extensão -1 8
Os arquivos Flex são capazes de conter um pouco menos de 512 GB, especificamente 540.142.534.656 bytes contra 549.235.720.192 com DAE-256, mas têm a vantagem de que os arquivos pequenos crescem um bloco de cada vez, depois 8, depois 32, depois 256, em oposição a sempre 256 blocos de cada vez.
Você não deve montar um disco contendo arquivos flex em um módulo pré-18.0; existem ferramentas que permitem examinar facilmente um disco para a presença de arquivos flex. Se você o fizer acidentalmente, os arquivos não serão visíveis e não poderão ser acessados. Tais arquivos ou qualquer diretório contendo arquivos flex não podem ser excluídos e assim permanecerão intactos se o disco for movido de volta para um módulo rodando 18.0+. Entretanto, se você salvar em um módulo pré-18.0, todos os arquivos flex serão eliminados e o espaço será recuperado.
Ferramentas
- Localização de arquivos de fluxo de 64 bits em um módulo
Quando você precisa mover um disco para uma versão mais antiga do VOS, você precisa localizar arquivos que são incompatíveis com a versão mais antiga. Um comando está disponível para ajudar com isto:
locate_stream_files -form
---------- locate_stream_files ---------
nomes_do_diretório:
-depth:
-tipo: 64 bits
-brief: não
-long: não
-O tipo também pode ser flexível, esparso ou grande (que localizará arquivos de 64 bits com aquela característica específica), ou todos (que localizará todos os arquivos de fluxo).
Dependendo da profundidade, os diretórios subordinados são pesquisados e se o arquivo possui algum dos atributos (não especificados por tipo), são mostradas também informações a respeito disso e o tamanho da extensão. Se nenhum nome de diretório for dado, então todos os discos no módulo são pesquisados a partir da raiz. Por exemplo:
locate_stream_files -type 64-bit
Verificação de diretórios em disco %swsle#raid0-1...
%swsle#raid0-1:
smb_test.stm64 (FLEX/large)
smb_test.stmb
Total de 2 arquivos de fluxo de 64 bits.
Verificação de diretórios em disco %swsle#raid0-2...
%swsle#raid0-2:
big_stream (FLEX)
smb_test.stm (FLEX)
smb_test.stm64a (FLEX/large)
Total de 3 arquivos de fluxo de 64 bits.
Verificação de diretórios em disco %swsle#Raid4...
%swsle#Raid4>otto:
b3 (DAE-8)
grande (DAE-256/largura/espaço)
…
- Comparação de blocos
Nas versões 17.2 e 18.0, novas opções estão disponíveis para o comando compare_files, que são úteis para arquivos stream. A comparação bloco a bloco de tipos de arquivos estruturados VOS normalmente não é útil porque dois blocos com valores diferentes muitas vezes representarão os mesmos registros lógicos. Por exemplo, os dados não utilizados nos registros de um arquivo relativo, além de seu comprimento atual, são imprevisíveis. Além disso, os arquivos seqüenciais contêm bytes de preenchimento indefinidos. O conteúdo dos blocos de arquivos seqüenciais estendidos é completamente diferente se o tamanho do registro for diferente, embora representem os mesmos registros lógicos.
No entanto, a comparação de blocos pode, às vezes, ser útil para arquivos fixos e de fluxo contínuo. O problema é que a comparação_arquivos é orientada a registros e projetada para mostrar diferenças em termos de números de registros (ou números de linhas) que podem ser localizados usando um editor. Isto tem apresentado problemas para arquivos de fluxo binário que não estão organizados em termos de registros. Como o tamanho do registro para qualquer arquivo é limitado a 32767 bytes, usando s$seq_read em um arquivo stream quando uma seqüência de mais de 32k bytes ocorre sem um delimitador de registro NL interveniente entregará os próximos 32767 caracteres, e não distinguirá se o próximo byte foi um NL ou não. Isto torna ambíguo o resultado da comparação orientada a registros para arquivos de fluxo que contêm valores binários em vez de uma seqüência de caracteres separados pelo caracter NL.
Este problema foi tratado no release 17.2; compare_files detectará casos onde o falso sucesso pode ter ocorrido anteriormente - especificamente quando 32767 caracteres seguidos por um NL iguala 32767 caracteres não seguidos por um NL. Se isto ocorrer, um erro será relatado indicando que o arquivo de fluxo contém registros > 32767. Se isto nunca ocorrer, então os resultados orientados a registros serão válidos e podem ser confiáveis. Mas em qualquer caso, quando tudo o que você quer fazer é garantir que os arquivos sejam idênticos, comparar os blocos de um arquivo não estruturado é muito mais rápido do que o método orientado a registros. O problema com a comparação de blocos é que, sem registros para servir de guia, a comparação após a primeira discrepância é muitas vezes sem sentido.
No release 17.2, a opção -compare_blocks foi adicionada ao comando compare_files para este fim. Isto detectará rapidamente se os arquivos não estruturados são ou não idênticos para bloco e identificará o bloco no qual eles diferem. Para o caso raro, onde a diferença é causada por uma sobreposição (certos bytes sendo modificados em oposição a inseridos ou excluídos) e o resto dos arquivos são idênticos, a opção -continuar também está disponível. Isto mostrará o intervalo de blocos no restante do arquivo que diferem. Se um byte foi inserido, por exemplo (em oposição à sobreposição), então todos os blocos restantes serão diferentes; isto é, a sincronização, como é feito com a comparação de registros, não é possível com a comparação de blocos. Mas no caso aludido, esta informação adicional poderia determinar que a única diferença eram alguns bytes sobrepostos em alguns blocos, talvez representando algo como um carimbo da hora.
Como exemplo de -compare_blocos com -continuar:
compare_files flex dae256 -compare_blocks -continuar
A (%swsle#m111_mas>Stratus>Newman>flex) não corresponde a B (%swsle#m111_mas>Stratus>Newman>dae256).
- Os blocos de dados de 2 a 24 são diferentes.
- Os blocos de dados de 33 a 488 são diferentes.
- 272 blocos adicionais no arquivo B.
- Comparação de arquivos esparsos
O comando compare_files analisa todos os blocos fisicamente presentes em um arquivo. Isto pode ser um problema em arquivos esparsos, porque um bloco de zeros binários pode aparecer como um bloco alocado em um arquivo, mas não estar presente em outro. Os arquivos podem ser logicamente idênticos, mas não bloco por bloco. De fato, o uso de copy_file eliminará blocos de zeros binários no alvo, e se algum existir, isto garantirá que a fonte e o alvo não serão blocos para bloco idêntico.
Isto também é um problema em termos de extensão baseada em arquivos de fluxo porque todos os blocos em uma extensão são sempre instanciados mesmo que contenham todos os zeros binários. Isso significa que os blocos em um arquivo de extensão esparsa podem parecer diferentes dos blocos em um arquivo não-extenso idêntico, mesmo que representem exatamente os mesmos dados. A execução do copy_file não pode eliminar blocos zero em uma extensão.
O exemplo que mostra o uso de -continuar acima realmente envolve dois arquivos idênticos, exceto que um tem extensões DAE-256 e o outro tem extensões flexíveis.
Assim, um arquivo DAE-8 com conteúdo "abc" conterá um bloco com "abc" seguido de outros 7 blocos com zeros binários. Um arquivo não-extenso (ou arquivo flex) conterá apenas um bloco com "abc", e um arquivo DAE-16 conterá um bloco "abc" seguido de 15 blocos de zeros binários.
Usando o comando compare_files com -compare_blocks mostrará todos esses arquivos como sendo diferentes, mesmo que todos representem os mesmos dados de arquivo. Na versão 18.0, a opção -compare_all_blocks está disponível para esta situação. Isto faz com que o copy_file instantifique logicamente blocos ausentes em arquivos sendo comparados, resultando em uma verdadeira comparação bloco a bloco com as diferenças causadas pela escassez eliminada. Os blocos em falta nos arquivos stream64 são considerados todos os zeros binários enquanto nos fixos (ou todos os outros tipos de arquivo) são considerados binários -1′s (todos FFFF).
Em um arquivo muito esparso, isto pode tornar a comparação muito mais lenta do que usar as opções -compare_blocks, mas ainda assim significativamente mais rápida do que usar a comparação padrão orientada a registros. Normalmente, ela só é necessária ao comparar blocos de arquivos com extensões diferentes, embora existam outros casos, como mencionado, em que a escassez pode diferir. Isto é útil também para arquivos fixos com extensões diferentes.