A voir également:
- TAR end-of-archive entry
- Archive story instagram - Guide
- Path of exile 2 - Guide
- No bag entry - Forum MacOS
- Archive story instagram disparu ✓ - Forum Instagram
- Exemple planning 1 week-end sur 3 - Télécharger - Outils professionnels
1 réponse
Bonjour,
La commande que tu cites est incomplète et indépendante de cette considération de 512 octets.
Si on lit la page wikipedia de tar, on voit qu'une archive tar est constituée d'un header et de blocs de données. Chaque fichier stocké dans l'archive est stocké sur un ou plusieurs blocs de données. Chaque bloc fait par défaut 512 octets, et chaque début de fichier est aligné sur un début de bloc. C'est ce qui conduit à introduire du padding (= rajouter des 0 jusqu'au prochain alignement) en fin de fichier pour que le prochain fichier stocké soit aligné. .
Prenons un exemple. Supposons qu'on stocke un fichier à partir du bloc dont l'adresse est @.
Bonne chance
La commande que tu cites est incomplète et indépendante de cette considération de 512 octets.
Si on lit la page wikipedia de tar, on voit qu'une archive tar est constituée d'un header et de blocs de données. Chaque fichier stocké dans l'archive est stocké sur un ou plusieurs blocs de données. Chaque bloc fait par défaut 512 octets, et chaque début de fichier est aligné sur un début de bloc. C'est ce qui conduit à introduire du padding (= rajouter des 0 jusqu'au prochain alignement) en fin de fichier pour que le prochain fichier stocké soit aligné. .
Prenons un exemple. Supposons qu'on stocke un fichier à partir du bloc dont l'adresse est @.
- De la plage @ à @+1000 : tu retrouves ce fichier de données
- Le plus petit multiple de 512 supérieur à 1000 est 1024, donc le prochaine alignement correspond @+1024. Donc de @+1000 à @+1024, tar écrit des 0 (padding). Il n'y a pas de raison de faire de padding au niveau du dernier bloc.
- L'éventuel fichier de données suivant (s'il y en a un) est écrit à partir de @+1024
Bonne chance
