O ile wiem, nie ma sposobu, aby powiedzieć, dd
aby użyć pad 0xFF
. Ale istnieje obejście.
Najpierw utwórz plik o wymaganej długości wypełniony 0xFF
:
$ dd if=/dev/zero ibs=1k count=100 | tr "\000" "\377" >paddedFile.bin
100+0 records in
200+0 records out
102400 bytes (102 kB) copied, 0,0114595 s, 8,9 MB/s
tr
służy do zamiany zer na 0xFF
. tr
oczekuje argumentów ósemkowych. 0xFF
w ósemce jest \377
.
Wynik:
$ hexdump -C paddedFile.bin
00000000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
00019000
Następnie wstaw plik wejściowy na początku pliku „wypełnianego”:
$ dd if=inputFile.bin of=paddedFile.bin conv=notrunc
0+1 records in
0+1 records out
8 bytes (8 B) copied, 7,4311e-05 s, 108 kB/s
Zwróć uwagę, conv=notrunc
która mówi, dd
aby nie obcinać pliku wyjściowego.
Przykładowy plik wejściowy:
$ hexdump -C inputFile.bin
00000000 66 6f 6f 0a 62 61 72 0a |foo.bar.|
00000008
Wynik:
$ hexdump -C paddedFile.bin
00000000 66 6f 6f 0a 62 61 72 0a ff ff ff ff ff ff ff ff |foo.bar.........|
00000010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
00019000
paddedFile.bin
jest wypełnionyc3 bf
. Zastanawiam się dlaczego? edycja: superuser.com/questions/1349494/…Możliwym ulepszeniem odpowiedzi lesmany jest działanie na pliku w miejscu. Może to być znacznie szybsze w przypadku dużych plików wejściowych, a także rzadkie pliki rzadkie. Jednak w wielu sytuacjach nie chcesz modyfikować pliku wejściowego, więc ta metoda będzie nieodpowiednia.
Poniższy przykład zaczyna się od dużego, rzadkiego pliku wejściowego i uzupełnia go do rozmiaru 1 GB znakami FF. Po prostu zmień
newsize
na żądaną wartość. Jak widać,dd
część zajmuje tylko ułamek sekundy, mimo że ten plik jest bardzo duży.źródło