Qu'est-ce que le dossier __MACOSX?


152

Quels sont ces dossiers __MACOSX que je vois régulièrement dans les fichiers zip créés par des personnes sous OSX? Certains prennent jusqu'à 30% du fichier.

Quel programme produit ces dossiers __MACOSX et comment les utilisateurs de mac peuvent-ils éviter cette erreur?


8
Ils sont super irritants, oui, et généralement inutiles car les ressources sont si souvent vides. Mais au moins, ils sont inoffensifs, contrairement à l'approche non standard que Apple a adoptée pour des archives de plus de 4 Go avec les éléments intégrés à OS X, ce qui confondra tout autre outil et rompra à nouveau pour des fichiers suffisamment volumineux. Et bon, ça pourrait être pire, cela pourrait être de stocker deux copies de chaque fichier avec le même nom, une pour les données et une pour la fourchette de ressources, rendant souvent impossible l'accès à l'une ou à l'autre, comme auparavant. Oh Apple, pourquoi détestes-tu les formats de fichiers standard?
bobince

3
@bobince: en fait, les fourchettes de ressources étaient une très bonne idée ... à l'époque. De nos jours, le même effet est obtenu en stockant les ressources sous forme de fichiers individuels, dont la plupart ressemblent beaucoup aux formats de fichiers standard.

16
Rien de mal avec les métadonnées en tant que telles, c'est juste qu'Apple a le talent de créer ses propres formats et de déconner les formats existants avec des extensions gratuitement incompatibles! Avoir les données de type contenu sous forme de métadonnées est en soi une bonne chose et cela me désole que OS X s'oriente plutôt vers le piratage Windows des extensions de fichiers. Bien que ce ne soit pas aussi grave que sous Linux, où le système de fichiers prend en charge le stockage de métadonnées Content-Type, mais aucun ordinateur de bureau ne l’utilise, préférant un mélange complètement fragmenté de modèles d’extensions de noms / noms de fichiers et de reniflement de contenu (urgh!). Soupir, OS hein?
Bobince

@bobince: Mais oui, au moins le format qu'ils ont fait pour cela ne fait aucun préjudice réel, autres que encombrent légèrement les listes de répertoires et de perdre essentiellement 1 inode et 1 bloc par fourchette de ressource vide extrait, sauf si vous utilisez quelque chose comme NTFS (qui stockera le contenu du fichier dans la MFT pour de tels petits fichiers), auquel cas il ne perd que l’inode (entrée MFT).
SamB

9
Peut être résolu après le fait parzip -d filename.zip __MACOSX/\*
Chris Johnson

Réponses:


52

http://www.realsoftware.com/listarchives/gettingstarted/2005-09/msg00328.html

Apple offre une fonctionnalité intégrée pour les fichiers ZIP sous OS X 10.3 et versions ultérieures. Ces fichiers sont le résultat du stockage sûr par Apple des fourchettes de ressources. Vous ne verriez jamais ces fichiers sous OS X 10.3 ou une version ultérieure, mais comme Windows et les autres systèmes d'exploitation ne comprennent pas cette forme spéciale de ressources de ressources, ils apparaîtront dès que vous les verrez.


4
Il ne s’agit pas uniquement de ressources de ressources, tout ce qui dépasse le contenu de fichier de base est placé dans le fichier AppleDouble. Apple s'éloigne des ressources, mais vers des attributs tels que les attributs étendus, qui seront également stockés dans le conteneur AppleDouble.
Gordon Davisson

14
Vous le faites sonner comme une fonctionnalité. Les fichiers .zip manquent intentionnellement dans le service des métadonnées. Si vous voulez des métadonnées, utilisez un format différent, pas un Mac. Exemple de bonne implémentation zip + métadonnées: .jar
Zenexer

16
lien mort, s'il vous plaît réparer.
Lucas - Better Coding Academy

71
"Depuis Windows et les autres systèmes d'exploitation ne comprennent pas" - Ugh. Je déteste juste ce genre de terminologie
Joe Plante

5
Vient de le découvrir: si vous utilisez un Mac, vous utiliserez la ligne de commande unzip filename.zippour décompresser le répertoire __MACOSX /, ce que vous ne voulez pas, mais que vous ferez comme il convient open filename.zip.
Edward Falk

107

Voici un lien qui explique assez bien. Je suppose qu'il est un peu tard pour aider Yada, mais pour la postérité.

Explication de la fourchette de ressources sur Wikipedia

Le reste est mon avis:

@ nickf: Ne jamais voir ces fichiers n'est pas une FONCTION de ces versions d'OS X, c'est une FLAW. Les gens produisent des données, les emballent, les stockent sur différents supports, etc. Ils ont besoin de savoir ce qui est nécessaire ou non. Le cacher les garde dans le noir.

La vieille mauvaise idée de cacher des choses aux utilisateurs: un programmeur, soucieux de l'opportunité d'accomplir son propre travail, abuse de quelque chose dans le domaine de l'utilisateur final, pour se faciliter la tâche.

Dans ce cas, il a stocké les métadonnées dans l'espace de données de l'utilisateur, il les a ensuite cachées à l'utilisateur. Il a raté la grande image: l'utilisateur ne se rendra pas compte des détails cachés. Quand il empaquetera ses données et les expédiera dans un endroit imprévu par le programmeur, les pièces manquantes ne seront pas expédiées ou des pièces inconnues arriveront, que ni l'utilisateur ni le destinataire ne peuvent expliquer.

Cacher des choses à l'utilisateur est mauvais. Cela suppose que l'utilisateur est stupide, alors que le programmeur est stupide ou paresseux.

Pour être clair, cette mauvaise habitude ne se limite pas à MAC. C'est partout. C'est une conséquence du fait que les programmeurs tombent amoureux de leurs propres projets et que les fournisseurs donnent la priorité à leurs propres objectifs avant les besoins de l'utilisateur final.

En bref.

__MACOSX:
excréments de programmeurs à l'odeur bizarre qui émergent de sous le tapis où ils ont été balayés.

Programmeurs et vendeurs: S'il vous plaît, gardez les choses à l'air libre. Lorsque vous les cachez, vous vous rendez stupide et l'utilisateur mal informé.


12
Cette réponse serait meilleure si c'était juste une réponse. Le discours prolongé sur les programmeurs stupides et les utilisateurs paresseux y nuit.
Kristopher Johnson

1
@pbernatchez En fait, si vous vous arrêtez pour apprendre à quoi ressemblent les choses et comment elles ont évolué, vous ne laisseriez probablement pas ici vos propres "crottes" arrogantes et arrogantes. Les fourchettes de ressources constituaient un détail (vraiment sympa!) De la mise en œuvre antérieure à Mac OS X et les utilisateurs ne les trouvaient que lors de l'interface avec d'autres systèmes; Depuis les années 90, Apple a progressivement migré vers un monde sans ressources, mais toujours en arrière pour préserver la compatibilité. "Stocker les métadonnées dans l'espace de données de l'utilisateur"? WTF? De quelle manière faut-il définir "métadonnées" et "espace de données de l'utilisateur" pour le dire? Vous devez détester les systèmes de fichiers!
hmijail

3
"Cacher des choses à l'utilisateur est mauvais". Bon sang, vous devez également détester tout type d’interfaces utilisateur, de bibliothèques, d’abstraction, et ... enfin, tout type de programmation et d’ordinateurs plus avancés qu’un abaque.
hmijail

4
Cela ne répond pas à la question. Après avoir lu cette réponse, je n'ai toujours aucune idée des métadonnées contenues dans le dossier _MACOSX ni des fourchettes de ressources. Je suppose que les gens votent de nouveau pour cela simplement parce qu’ils sont d’accord avec la diatribe?
Atte Juvonen

1
Bien que je convienne que le ton chargé d'émotion n'est pas utile, je suis tout à fait d'accord pour dire que créer des choses cachées qui sont parfois nécessaires est une très mauvaise idée, précisément comme indiqué dans cette réponse: les utilisateurs vont soit (a) ne pas envoyer de fichiers cachés qui sont nécessaire, ou (b) expédier des fichiers cachés que le destinataire peut voir et ne pas comprendre. Ces fichiers doivent être visibles ou les données doivent être incorporées dans les fichiers d'une manière qui est signalée comme "désactivable" par d'autres systèmes d'exploitation. Les fichiers et les répertoires cachés doivent être principalement utilisés pour protéger les utilisateurs et non pour les garder dans le noir.
Mike Williamson

16

Pour répondre à votre dernière question:

Comment les utilisateurs de Mac peuvent-ils éviter cette erreur?

Les utilisateurs de Mac OS X peuvent installer un utilitaire d'archivage tiers tel que Keka , puis lui dire de ne pas utiliser Resource Forks, puis de le définir comme compresseur par défaut.


Comment faire cela avec Keka

Dites à Keka de ne pas utiliser les fourchettes de ressources

  1. Ouvrir Keka sans fichier (depuis Launchpad, Spotlight, etc.)
  2. Appuyez sur ⌘ Cmd+ ,pour ouvrir les préférences
  3. Sélectionnez l' onglet Compression
    Keka "Compression" onglet sélectionné
  4. Cochez "Exclure les ressources de ressources Mac (par exemple: .DS_Store)"
    Une case à cocher indiquant "Exclure les fourchettes de ressources Mac (ex: .DS_Store)"

Faire de Keka le compresseur par défaut

  1. Dans la même fenêtre de préférences Keka
  2. Sélectionnez l' onglet Général
    Keka "Général" onglet sélectionné
  3. Cliquez sur "Définir Keka comme compresseur / décompresseur par défaut" [sic]
    entrez la description de l'image ici

1
Cela pourrait être amélioré en ajoutant des informations sur les 2 dernières étapes, "dites-lui de ne pas utiliser Resource Forks, puis définissez-le comme compresseur par défaut".
Steven C. Howell

@ stvn66 Fait! Juste pour votre information, cependant, cela sort généralement du cadre de ces questions, c'est pourquoi je ne l'ai pas fait au début.
Ben Leggiero

2
Vote négatif, désolé. Je ne suis pas fan de l'installation d'un logiciel tiers pour résoudre un problème qui peut être résolu avec le logiciel par défaut. Comme Chris Johnson l’a souligné ci-dessus, zip -dles fourchettes de ressources seront supprimées d’un fichier zip. En fait, je pense que si vous utilisez zip en premier lieu, les fourchettes de ressources ne sont pas ajoutées en premier lieu.
Edward Falk

1
@ EdwardFalk C'est juste! Cette réponse était destinée à résoudre le "Comment puis-je le faire se comporter toujours de cette façon?" problème, pas le "Comment puis-je le faire se comporter de cette façon une fois?" un.
Ben Leggiero
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.