Bizarre bug dans 'tar' n'incluant pas les fichiers nommés .__ init__.py


3

Est-ce que quelqu'un sait pourquoi tarn'inclut pas les fichiers nommés .__init__.py(notez le point)?

$ mkdir /tmp/work && cd /tmp/work
$ mkdir foo
$ touch foo/.__init__.py
$ touch foo/.namespace__init__.py
$ tar czf foo.tar.gz foo

$ mkdir e && mv foo.tar.gz e/ && cd e/
$ tar zxf foo.tar.gz
$ ls -al foo/
total 0
drwxr-xr-x  2 sridharr  wheel  102 14 Mar 17:16 .
drwxr-xr-x  3 sridharr  wheel  136 14 Mar 17:17 ..
-rw-r--r--  1 sridharr  wheel    0 14 Mar 17:16 .namespace__init__.py
$ 

$ echo ".__init__.py file is missing. WTF? This is OSX 10.6"

Mise à jour : tar semble ignorer les fichiers commençant par des ._caractères; Pourquoi?

Mise à jour 2 : Je ne peux pas reproduire cela sous Linux.


Bizarre que la fonction tar sur mac ne puisse pas faire cette distinction.
DaveParillo

Ironiquement, il y a une question qui demande comment créer des fichiers d' tar exclusion ._ .
Grawity

Réponses:



6

Certaines variables d'environnement non documentées (?) Peuvent être utilisées pour désactiver le traitement spécial d'attributs étendus et / ou de fourchettes de ressources dans tar (et pax , à sa juste valeur). rsync a -E/ --extended-attributesoption pour activer ( ! ) cette manipulation, mais sur certains non-Apple rsync s -Esignifie à la --executabilityplace.

Sur Mac OS X 10.4 (la première version qui a créé ces ._*membres d'archive AppleDouble ), la variable d'environnement est COPY_EXTENDED_ATTRIBUTES_DISABLE. Dans Leopard et Snow Leopard, la variable est COPYFILE_DISABLE. En règle générale, les variables doivent simplement être définies. N'importe quelle valeur fera l'affaire (même la chaîne vide), mais truesemble être traditionnelle. Ainsi:

COPY_EXTENDED_ATTRIBUTES_DISABLE=true COPYFILE_DISABLE=true tar …

La définition de cette variable a les effets suivants:

  • Lors de la création / mise à jour des archives:
    • Empêche la création de ._*membres d'archives lors de l'archivage de fichiers avec des attributs étendus.
    • Permet la création de ._*membres d'archives lors de l'archivage de ._*fichiers réels .
  • Lors de l'extraction des archives:
    • Les ._*membres de l'archive sont extraits en tant que fichiers simples au lieu de restaurer les attributs étendus dans le fichier associé.

En bref, définir ces variables rend tar , et al. agissent comme ils le feraient sur (par exemple) Linux.

Si vous avez rarement besoin d'archiver des fichiers dotés d'attributs étendus ou de ressources, et que vous ayez éventuellement besoin d'archiver ou d'extraire des ._*fichiers réels , vous pouvez envisager de définir et d'exporter ces variables dans l'un de vos fichiers d'initialisation du shell:

# Tell tar, pax, etc. on Mac OS X 10.4+ not to archive
# extended attributes (e.g. resource forks) to ._* archive members.
# Also allows archiving and extracting actual ._* files.
COPY_EXTENDED_ATTRIBUTES_DISABLE=true COPYFILE_DISABLE=true
export COPY_EXTENDED_ATTRIBUTES_DISABLE COPYFILE_DISABLE

Ces ._*fichiers sont également utilisés pour stocker des attributs étendus sur des systèmes de fichiers qui ne les prennent pas en charge, le plus souvent les variantes FAT. Ces variables ne vous aideront pas vraiment lorsque vous manipulez des ._*fichiers sur d’autres systèmes de fichiers, mais uniquement sur des archives.

Le système de fichiers HFS + utilisé dans Mac OS X est parfaitement capable de stocker des ._*fichiers réels . Ainsi, une fois que vous utilisez les variables pour extraire les fichiers dans le système de fichiers, vous pouvez y accéder correctement de toutes les manières habituelles.



1

Je ne peux pas répliquer ceci sur un hôte Debian 5.0. Peut-être existe-t-il un bogue dans la version de tar installée sur le système que vous utilisez? Quelle version de * nix utilisez-vous?

$ mkdir foo
$ touch foo/.namespace__init__.py
$ touch foo/.__init__.py
$ tar -czvf foo.tar.gz foo/
foo/
foo/.namespace__init__.py
foo/.__init__.py

$ # example the file
$ tar -tzvf foo.tar.gz
drwxr-xr-x cfrancy/cfrancy   0 2010-03-14 17:34 foo/
-rw-r--r-- cfrancy/cfrancy   0 2010-03-14 17:34 foo/.namespace__init__.py
-rw-r--r-- cfrancy/cfrancy   0 2010-03-14 17:34 foo/.__init__.py
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.