permissions (ouvrir des documents transférés d'un autre Mac)
- Créateur du sujet Goanna
- Date de début
M
Membre supprimé 1060554
Invité
Salut Goanna.
Ahaaa! Une énigme comme je les aime : si concise qu'elle donne lieu à des conjectures_multiples [je sais d'ailleurs en embuscade ce maître déchiffreur d'énigmes qu'est François_MacG
]
La réponse à la question de jp.pilet fournirait une information précieuse : sur un fichier quelconque pris comme exemplaire de l'ensemble, savoir qui est le propriétaire, et quel est le groupe avec les permissions appendues à ces accédants. Mais comme cette réponse n'a pas été (encore) apportée - me voilà dans mon élément favori : la conjecture_formelle excluant toute information supplémentaire par rapport à l'énoncé premier du problème.
Supposons donc que sur le MacBook (source), les fichiers anciennement créés l'ont été à partir de la session-admin aborigène, dont je vais supposer que le nom de compte abrégé est : admin. Régulièrement, les droits de ces fichiers sont :
c'est-à-dire, si l'on ouvrait une fenêtre d'information du Finder dans cette session du MacBook :
Que va-t-il se passer si, la fonctionnalité 'Partage de fichiers' activée sur les 2 Macs, Goanna se connecte depuis son nouvel iMac, par l'intermédiaire du serveur : afp://, aux fichiers du MacBook créés par admin en s'étant identifiée pour ce faire par ce même nom abrégé d'utilisateur = admin assorti de son mot-de-passe de session-admin?
Je conjecture 2 cas de figure possibles :
À partir de ce contexte conjectural binaire, j'entrevois plusieurs dérivés possibles :
Ahaaa! Une énigme comme je les aime : si concise qu'elle donne lieu à des conjectures_multiples [je sais d'ailleurs en embuscade ce maître déchiffreur d'énigmes qu'est François_MacG
] La réponse à la question de jp.pilet
fournirait une information précieuse : sur un fichier quelconque pris comme exemplaire de l'ensemble, savoir qui est le propriétaire, et quel est le groupe avec les permissions appendues à ces accédants. Mais comme cette réponse n'a pas été (encore) apportée - me voilà dans mon élément favori : la conjecture_formelle excluant toute information supplémentaire par rapport à l'énoncé premier du problème.♤
Supposons donc que sur le MacBook (source), les fichiers anciennement créés l'ont été à partir de la session-admin aborigène, dont je vais supposer que le nom de compte abrégé est : admin. Régulièrement, les droits de ces fichiers sont :
Bloc de code:
-rw-r--r-- admin staffc'est-à-dire, si l'on ouvrait une fenêtre d'information du Finder dans cette session du MacBook :
admin : lecture/écriture
staff : lecture seule
everyone : lecture seule
staff : lecture seule
everyone : lecture seule
Que va-t-il se passer si, la fonctionnalité 'Partage de fichiers' activée sur les 2 Macs, Goanna se connecte depuis son nouvel iMac, par l'intermédiaire du serveur : afp://, aux fichiers du MacBook créés par admin en s'étant identifiée pour ce faire par ce même nom abrégé d'utilisateur = admin assorti de son mot-de-passe de session-admin?
♧
Je conjecture 2 cas de figure possibles :
- Soit la session-admin que Goanna a ouverte sur son nouvel iMac comme compte aborigène (501) porte exactement le même nom abrégé d'utilisateur que celui du compte-admin aborigène du MacBook = admin. Dans ce cas de figure, un fichier qui apparaît dans le volume du MacBook que le serveur permet de monter, si l'on fait une demande d'information dessus dans une fenêtre d'info du Finder, va faire apparaître logiquement les droits :
admin : lecture/écriture
staff : lecture seule
everyone : lecture seule
en suite de quoi, si admin de l'iMac, sans déplacer ces fichiers du volume monté par le serveur afp://, engage un processus de manipulation sur eux, il peut le faire avec l'identé nominale du propriétaire qui a créé ces fichiers sur le MacBook. Il a donc sur les fichiers adhérents au volume monté par le serveur les permissions de : lecture/écriture.
- Soit la session-admin que Goanna a ouverte sur son nouvel iMac comme compte aborigène (501) ne porte pas le même nom abrégé d'utilisateur que celui du compte-admin aborigène du MacBook = admin, mais un nom différent que nous supposerons pour l'exercice conjectural : néo. Dans ce cas de figure, un fichier qui apparaît dans le volume du MacBook que le serveur permet de monter, si l'on fait une demande d'information dessus dans une fenêtre d'info du Finder, va faire apparaître logiquement les droits :
inconnu : lecture/écriture
staff : lecture seule
everyone : lecture seule
en suite de quoi, si néo de l'iMac, sans déplacer ces fichiers du volume monté par le serveur afp://, engage un processus de manipulation sur eux, il ne peut le faire avec l'identé nominale du propriétaire qui a créé ces fichiers sur le MacBook, càd. admin, car même si néo s'est connecté au serveur avec les identifiants de l'admin du MacBook pour pouvoir monter son volume, il garde ensuite en tant qu'opérateur sur le volume l'identité nominale du visiteur : néo pour lequel l'identité du propriétaire des fichiers sur le MacBook (= admin) se trouve masquée et n'apparaît que sous la rubrique : inconnu. En cette qualité de visiteur du volume monté grâce au serveur, les fichiers adhérents à ce volume sans en avoir été déplacés ne lui offrent donc pas les permissions de : lecture/écriture du propriétaire, mais seulement les permissions de : lecture seule de membre du groupe staff dont l'identité passe-partout joue le rôle de dénominateur commun formellement identique entre les 2 Macs. Néo devrait donc pouvoir les lire (interprétation de 'ouvrir' un fichier, puisque un fichier n'étant pas un répertoire, la lecture de l'espace graphique de cet élément n'est pas subordonnée à un droit préalable d'exécution = x permettant d'exécuter_l'entrée à l'espace du répertoire avant de pouvoir en lire les éléments inclus).
♡
À partir de ce contexte conjectural binaire, j'entrevois plusieurs dérivés possibles :
- L'utilisateur de l'iMac, qu'il ait la même identité nominale que celui du MacBook = admin, ou une autre identité nominale = néo, donc au minimum des permissions reconnues (si l'on ouvre une fenêtre d'info du Finder) de lecture (directe ou en tant que membre de staff) sur les fichiers adhérents au volume du MacBook monté par le serveur, nonobstant ne peut pas 'ouvrir', càd. lire lesdits fichiers. Alors, une possibilité est que : un fichier (à la différence d'un répertoire) s'ouvrant nécessairement par une application capable de gérer son extension, le nouvel iMac serait dépourvu, pour un certain nombre de fichiers considérés, des applications capables d'ouvrir les fichiers du MacBook. Cas classique : fichiers AppleWorks, dotés de l'extension .cwk, créés par ce logiciel PPC sur le MacBook dont l'OS serait au maximum «Snow Léopard 10.6», tandis que l'iMac supporterait l'OS Intel : «Mavericks 10.9 incapable de supporter les applications PPC. Les fichiers ne seraient donc pas illisibles pour une question de permissions, mais d'absence des applications capables de les lire. Ce ne serait donc pas tous les fichiers (∀ du MacBook qui seraient illisibles, mais quelques fichiers (∃.
- Aucun fichier adhérent au volume monté du MacBook par le serveur n'est lisible, même ceux dont l'extension (par exemple .pdf ou .rtf) requiert des applications forcément présentes sur l'iMac («Aperçu» ou «TextEdit») et qui dont sauraient le lire. On pourrait alors conjecturer que l'utilisateur de l'iMac est néo (un autre nominalement que le créateur des fichiers amdin du MacBook), et que les fichiers considérés ont des permissions du type :
admin : lecture/écriture
interdit à quiconque d'autre
soit :
Bloc de code:-rw------- admin staff
Il faudrait alors rétablir les droits sur ces fichiers. Un simple glisser-déposer des fichiers depuis le volume monté par le serveur à son répertoire d'utilisateur du volume-disque de l'iMac suffirait à établir l'utilisateur néo de l'iMac comme le propriétaire de la copie dans son espace d'opérations propriétaire (son répertoire de compte néo).
- L'opération de copie est impossible pour néo ☞ je ne peux pas croire à cette conjecture, car dès lors que néo peut exécuter_l'entrée au répertoire du volume, afin de 'browser' ses éléments inclus, ipso facto il possède la capacité de copie de ces éléments sur un autre volume où il a des droits d'écriture = celui de son répertoire d'utilisateur sur l'iMac, quand bien même il ne saurait pas les 'ouvrir' au sens d'en lire le contenu dans le cadre du volume monté du MacBook. Je présume donc le volume 'non_verrouillé'.
♢
Dernière édition par un modérateur:
Pour éviter ce genre de pataquès, je zippe mes fichiers avant de les transférer d'une machine à l'autre, surtout si le compte n'a pas le même UID.
Ça marche aussi après. Tu zippes. Tu dézippes. T'as tous les droits comme il faut.
Ça marche aussi après. Tu zippes. Tu dézippes. T'as tous les droits comme il faut.
Vous avez donné les solutions,
et je me pose toujours la question : comment se fait-ce ? :heu:
Normalement, un fichier copié ou collé dans un dossier prend les droits du dossier, puisqu'il y est créé. C'est ce que j'ai appris (ou compris) depuis Tiger, et c'était déjà comme ça avant.
Pour faire autrement (depuis Lion), il faut le vouloir = Comprendre l'option copier exactement
Le Partage de fichiers semble donc interférer. :mouais:
et je me pose toujours la question : comment se fait-ce ? :heu:
Normalement, un fichier copié ou collé dans un dossier prend les droits du dossier, puisqu'il y est créé. C'est ce que j'ai appris (ou compris) depuis Tiger, et c'était déjà comme ça avant.
Pour faire autrement (depuis Lion), il faut le vouloir = Comprendre l'option copier exactement
Le Partage de fichiers semble donc interférer. :mouais:
Ca suppose que tu aies les droits sur le fichier ZIP pour pouvoir le dézipper... :zen:
Oui. Parce que plusieurs choses doivent être considérées : le masque de création de fichier de l'utilisateur, son groupe primaire, les droits UNIX du dossier, les ACL éventuelles du dossier.
Ce n'est donc pas si aisé d'être déterministe quand on n'a pas toutes ces informations en tête.
En l'espèce, le dossier de partage est particulier.
une des raisons qui me font preferer d'autres voies quand il s'agit de " transferer" d'un mac à un autre
Tu les as car à l'arrivée tu obtiens des droits personnalisés sur le fichier.
Je n'aime pas trop ça, alors je zippe toujours avant de distribuer un fichier.
Sinon, on peut laisser le fichier en attente dans son répertoire Public ou dans /Users/Shared. En le copiant sur son bureau le correspondant obtiendra des droits normaux.
Mais bon, pour les transferts en nombres et volumineux de machine à machine, je suis comme Pascalformac : DD externe ou clef USB.
Dernière édition:
Je l'avais oublié, celui-là.
---------- Nouveau message ajouté à 14h55 ---------- Le message précédent a été envoyé à 14h54 ----------
Explique-moi, stp :
à l'arrivée = après zippage ? après dépôt ?
droits personnalisés = lesquels ?
sur le fichier = sur le fichier et/ou sur le zip ?
Au dépôt.
Tu prends un fichier d'un compte nicolas 501 sur un iMac A. Tu le transfères dans la boîte de dépôt d'un compte paulbismuth 502 sur un iMac B.
paulbismuth Personnalisé
nobody lecture/écriture
staff lecture
everyone lecture
Ce fichier peut être ouvert et modifié par paulbismuth et les droits deviendront :
paulbismuth Personnalisé
paulbismuth lecture/écriture
staff lecture
everyone lecture
Maintenant, si Nicolas zippe le fichier avant de le déposer, à la décompression Paul Bismuth obtient :
paulbismuth lecture/écriture
staff lecture
everyone lecture
Du classique.
Comme l'attribution des autorisations du dossier au fichier qui y est créé
= ouvrir une archive crée un fichier dans le dossier où siège l'archive.
Sauf, entre autres, dans la Boîte de dépôt depuis Leopard.
C'est simple comme une ACL d'héritage
Merci (à toi).
M
Membre supprimé 1060554
Invité
En lisant l'échange qui précède, il y a un point minuscule qui me turlupine (une de ces questions de détail qui interpellent les entomologistes quand ils observent un insecte à la binoculaire) dans ces deux déclarations de François qui se recoupent :
François pense que les droits qui se trouvent attachés à un dossier, déterminant les accédants à son espace et leurs permissions sur cet espace, ipso facto se trouvent hérités par les fichiers qu'un accédant autorisé va y insérer (que ce soit par création, par copier-coller passant par le presse-papier ou encore par déplacement à partir d'un autre lieu de l'espace global de l'OS). Il pense donc qu'il y a un effet_de_dossier automatique, transférant les droits du répertoire parent aux éléments enfants localisés dans son espace de parenté.
Pour prendre un exemple : mon nom-admin est maco. Dans un bash du «Terminal», je décide de créer un dossier home sur mon Bureau par la commande :
Par la commande :
je décide de fixer les accédants à : propriétaire = maco, groupe = admin et tout-venant inchangé.
Enfin par la commande :
je décide de fixer les permissions des accédants au dossier home ainsi : propriétaire maco = lecture/écriture/exécution (7) ; groupe admin = lecture/exécution (pas d'écriture = 5) ; tout-venant other = lecture/exécution (pas d'écriture = 5).
Si j'admets pour vraie l'idée de François = effet_de_dossier automatique faisant hériter des droits parents tout élément enfant relevant de l'espace parent du dossier, alors pour tout fichier toto que maco va créer/coller/déplacer dans l'espace de home, les droits devront à l'immixion de l'enfant toto dans le parent home reproduire en miroir ceux de home (sauf la permission exécutive sans pertinence pour un fichier qui n'est pas un binaire exécutable). Donc être de lecture/écriture pour maco et de lecture_seule pour admin.
Eh bien! Sur mon Mac, ce ne sera pas le cas, car le fichier toto que je vais créer dans le dossier home en tant que maco par la commande :
si je m'informe de ses droits, sera en : maco (propriétaire) = lecture/écriture ; staff (groupe) = lecture/écriture ; everyone (tout-venant) = lecture seule.
Le fichier toto, quoique créé par maco dans l'espace du dossier parent home, n'hérite pas par 'effet_de_dossier' automatique des droits du dossier parent. Car le groupe accédant de mon fichier toto est staff (et pas admin comme pour le dossier parent home) ; et les permissions du groupe staff du fichier toto sont en lecture/écriture, alors que celles du groupe du dossier parent (admin) sont en lecture seule.
Ce contre-exemple suffit à montrer que les droits d'accès à l'espace d'un dossier (droits appendus à ce dossier) ne déterminent pas de façon nécessaire et suffisante la nature des droits des fichiers qui vont se trouver localisés dans cet espace parent. Car ce n'est pas l'espace_parent qui crée l'élément inclus, c'est l'agent_utilisateur qui en est l'auteur (ici maco).
Or tout agent_utilisateur dans l'espace global d'un OS relève, pour ce qui est des permissions attribuées aux éléments qu'il crée (fichiers et dossiers), non de l'espace d'accueil dans lequel il va créer l'élément (l'espace_parent), mais du masque_d'utilisation universel par lequel le Système filtre les permissions que le créateur transmet à sa création. Il s'agit de l'umask, lequel par défaut est en valeur octale de 022 devant être défalqué à la valeur octale totale possible de 777 pour la création d'un dossier et de 666 pour la création d'un fichier. Ce qui donne par défaut : 755 pour les dossiers et 644 pour les fichiers.
Mais il se trouve que maco, sur son Mac, a édité le filtre umask dans un fichier de préférence /etc/launchd.conf chargé par le processus launchd avant l'ouverture des sessions d'utilisateurs, en choisissant la valeur octale : 002 => il s'ensuit que pour tout dossier que crée maco dans l'espace de l'OS, ses permissions sont de 775, et pour tout fichier, ses permissions de 664 - ce, indépendamment des permissions de l'espace d'accueil de l'élément créé. Si maco crée donc le fichier toto dans home, le fichier toto sera donc en 664 maco staff (car tel est le groupe par défaut que le Système impose à la création d'un élément) dans l'espace_parent du dossier home qui est de : 755 maco admin. Il n'y a donc pas eu héritage automatique des droits du dossier aux droits du fichier, car le fichier est en lecture/écriture : staff alors que le dossier parent est en lecture seule : admin
Si je généralise : un dossier qui porte des permissions d'écriture pour le groupe autorise par là un membre du groupe à affecter l'espace parent par l'ajout ou le retrait d'éléments ; mais cette permission d'affectation de l'espace parent ne détermine pas la nature des permissions de l'élément créé dans l'espace-parent. Les permissions sur l'espace-parent fixées au dossier qui l'inclut sont des permissions locales et pas chosales. Elles portent sur les lieux de résidence, pas sur les objets résidents. Elles permettent de vider ou de remplir l'espace d'accueil par des objets, elles ne fixent pas la nature des objets. L'essence de l'élément ne découle pas du lieu qu'il occupe. Si maco a une permission 'vider/remplir un lieu de l'espace parent' (= écrire), il peut remplir ce lieu avec un objet illisible et ininscriptible s'il a envie. S'il n'a pas édité l'umask par défaut du Système, dans un espace où tout membre du groupe a droit d'écriture locale (càd. de vider/remplir les lieux d'occupation), il va créer des objets (filtrés par 022) qui seront sans permission d'écriture de l'objet pour le même groupe.
En résumé : le lieu n'est pas l'objet qui occupe le lieu. Dès lors que j'ai la permission d'agir sur un lieu pour le vider/remplir, c'est mon profil d'agent_opérateur qui va fixer les permissions propres à l'objet que j'y crée (j'ai pris conscience de ce problème en étudiant ici, au message #2, un problème soulevé par nitrocastel qui se plaignait que dans un dossier de partage accessible sur un réseau local en lecture/écriture pour le groupe et le tout-venant, les fichiers y créés par les utilisateurs portaient des permissions de lecture seule pour le groupe et le tout-venant. Problème de permissions adhérentes à l'objet créé déterminées par l'umask indépendamment de la nature des permissions d'emploi des lieux déterminées par le dossier).
☞ pardon pour la disproportion entre la longueur du topo et la minceur du point, mais, je ne sais pas pourquoi, c'est un sujet qui me turlupine. Qu'est-ce que tu en penses, François? Et qu'en pensent bompi et Moonwalker?
François pense que les droits qui se trouvent attachés à un dossier, déterminant les accédants à son espace et leurs permissions sur cet espace, ipso facto se trouvent hérités par les fichiers qu'un accédant autorisé va y insérer (que ce soit par création, par copier-coller passant par le presse-papier ou encore par déplacement à partir d'un autre lieu de l'espace global de l'OS). Il pense donc qu'il y a un effet_de_dossier automatique, transférant les droits du répertoire parent aux éléments enfants localisés dans son espace de parenté.
♤
Pour prendre un exemple : mon nom-admin est maco. Dans un bash du «Terminal», je décide de créer un dossier home sur mon Bureau par la commande :
Bloc de code:
mkdir ~/Desktop/homePar la commande :
Bloc de code:
sudo chown maco:admin ~/Desktop/homeje décide de fixer les accédants à : propriétaire = maco, groupe = admin et tout-venant inchangé.
Enfin par la commande :
Bloc de code:
sudo chmod 755 ~/Desktop/homeje décide de fixer les permissions des accédants au dossier home ainsi : propriétaire maco = lecture/écriture/exécution (7) ; groupe admin = lecture/exécution (pas d'écriture = 5) ; tout-venant other = lecture/exécution (pas d'écriture = 5).
Si j'admets pour vraie l'idée de François = effet_de_dossier automatique faisant hériter des droits parents tout élément enfant relevant de l'espace parent du dossier, alors pour tout fichier toto que maco va créer/coller/déplacer dans l'espace de home, les droits devront à l'immixion de l'enfant toto dans le parent home reproduire en miroir ceux de home (sauf la permission exécutive sans pertinence pour un fichier qui n'est pas un binaire exécutable). Donc être de lecture/écriture pour maco et de lecture_seule pour admin.
Eh bien! Sur mon Mac, ce ne sera pas le cas, car le fichier toto que je vais créer dans le dossier home en tant que maco par la commande :
Bloc de code:
touch ~/Desktop/home/totosi je m'informe de ses droits, sera en : maco (propriétaire) = lecture/écriture ; staff (groupe) = lecture/écriture ; everyone (tout-venant) = lecture seule.
Le fichier toto, quoique créé par maco dans l'espace du dossier parent home, n'hérite pas par 'effet_de_dossier' automatique des droits du dossier parent. Car le groupe accédant de mon fichier toto est staff (et pas admin comme pour le dossier parent home) ; et les permissions du groupe staff du fichier toto sont en lecture/écriture, alors que celles du groupe du dossier parent (admin) sont en lecture seule.
♧
Ce contre-exemple suffit à montrer que les droits d'accès à l'espace d'un dossier (droits appendus à ce dossier) ne déterminent pas de façon nécessaire et suffisante la nature des droits des fichiers qui vont se trouver localisés dans cet espace parent. Car ce n'est pas l'espace_parent qui crée l'élément inclus, c'est l'agent_utilisateur qui en est l'auteur (ici maco).
Or tout agent_utilisateur dans l'espace global d'un OS relève, pour ce qui est des permissions attribuées aux éléments qu'il crée (fichiers et dossiers), non de l'espace d'accueil dans lequel il va créer l'élément (l'espace_parent), mais du masque_d'utilisation universel par lequel le Système filtre les permissions que le créateur transmet à sa création. Il s'agit de l'umask, lequel par défaut est en valeur octale de 022 devant être défalqué à la valeur octale totale possible de 777 pour la création d'un dossier et de 666 pour la création d'un fichier. Ce qui donne par défaut : 755 pour les dossiers et 644 pour les fichiers.
Mais il se trouve que maco, sur son Mac, a édité le filtre umask dans un fichier de préférence /etc/launchd.conf chargé par le processus launchd avant l'ouverture des sessions d'utilisateurs, en choisissant la valeur octale : 002 => il s'ensuit que pour tout dossier que crée maco dans l'espace de l'OS, ses permissions sont de 775, et pour tout fichier, ses permissions de 664 - ce, indépendamment des permissions de l'espace d'accueil de l'élément créé. Si maco crée donc le fichier toto dans home, le fichier toto sera donc en 664 maco staff (car tel est le groupe par défaut que le Système impose à la création d'un élément) dans l'espace_parent du dossier home qui est de : 755 maco admin. Il n'y a donc pas eu héritage automatique des droits du dossier aux droits du fichier, car le fichier est en lecture/écriture : staff alors que le dossier parent est en lecture seule : admin
♡
Si je généralise : un dossier qui porte des permissions d'écriture pour le groupe autorise par là un membre du groupe à affecter l'espace parent par l'ajout ou le retrait d'éléments ; mais cette permission d'affectation de l'espace parent ne détermine pas la nature des permissions de l'élément créé dans l'espace-parent. Les permissions sur l'espace-parent fixées au dossier qui l'inclut sont des permissions locales et pas chosales. Elles portent sur les lieux de résidence, pas sur les objets résidents. Elles permettent de vider ou de remplir l'espace d'accueil par des objets, elles ne fixent pas la nature des objets. L'essence de l'élément ne découle pas du lieu qu'il occupe. Si maco a une permission 'vider/remplir un lieu de l'espace parent' (= écrire), il peut remplir ce lieu avec un objet illisible et ininscriptible s'il a envie. S'il n'a pas édité l'umask par défaut du Système, dans un espace où tout membre du groupe a droit d'écriture locale (càd. de vider/remplir les lieux d'occupation), il va créer des objets (filtrés par 022) qui seront sans permission d'écriture de l'objet pour le même groupe.
En résumé : le lieu n'est pas l'objet qui occupe le lieu. Dès lors que j'ai la permission d'agir sur un lieu pour le vider/remplir, c'est mon profil d'agent_opérateur qui va fixer les permissions propres à l'objet que j'y crée (j'ai pris conscience de ce problème en étudiant ici, au message #2, un problème soulevé par nitrocastel qui se plaignait que dans un dossier de partage accessible sur un réseau local en lecture/écriture pour le groupe et le tout-venant, les fichiers y créés par les utilisateurs portaient des permissions de lecture seule pour le groupe et le tout-venant. Problème de permissions adhérentes à l'objet créé déterminées par l'umask indépendamment de la nature des permissions d'emploi des lieux déterminées par le dossier).
♢
☞ pardon pour la disproportion entre la longueur du topo et la minceur du point, mais, je ne sais pas pourquoi, c'est un sujet qui me turlupine
. Qu'est-ce que tu en penses, François? Et qu'en pensent bompi et Moonwalker?♔
Dernière édition par un modérateur:
En te lisant, je me dis que mon axiome est simple, mais complètement faux, comme souvent quand c'est simple.
Je me résouds à changer d'axiome : un fichier créé dans un dossier prend habituellement comme propriétaire celui du dossier.
Et tout de suite après, je me souviendrai des umask et ACL d'héritage : ça m'empêchera de rechuter.
Je me résouds à changer d'axiome : un fichier créé dans un dossier prend habituellement comme propriétaire celui du dossier.
Et tout de suite après, je me souviendrai des umask et ACL d'héritage : ça m'empêchera de rechuter.
J'en pense que c'est un peu long, comme lecture mat(ut)inale...
Comme je le disais ci-dessus, il y a effectivement à considérer divers paramètres :
- le masque de création de fichier propre à l'utilisateur
- son groupe primaire
- la nature du dossier où l'on crée le fichier/dossier
- les éventuelles caractéristyiques complémentaires définies par les ACL
- les trucs que j'oublie.
Le dossier partage est particulier car il a le sticky bit (non, ce n'est pas une grivoiserie), qui influe sur les caractéristiques des fichiers que l'on y crée (voir ici).
Un peu de lecture sur les ACL et les ACE, pour les plus courageux/ses.
Comme je le disais ci-dessus, il y a effectivement à considérer divers paramètres :
- le masque de création de fichier propre à l'utilisateur
- son groupe primaire
- la nature du dossier où l'on crée le fichier/dossier
- les éventuelles caractéristyiques complémentaires définies par les ACL
- les trucs que j'oublie.
Le dossier partage est particulier car il a le sticky bit (non, ce n'est pas une grivoiserie), qui influe sur les caractéristiques des fichiers que l'on y crée (voir ici).
Un peu de lecture sur les ACL et les ACE, pour les plus courageux/ses.
Un fichier créé par un utilisateur a pour propriétaire ce même utilisateur. Sauf exception, bien entendu.En te lisant, je me dis que mon axiome est simple, mais complètement faux, comme souvent quand c'est simple.
Je me résouds à changer d'axiome : un fichier créé dans un dossier prend habituellement comme propriétaire celui du dossier.
Et tout de suite après, je me souviendrai des umask et ACL d'héritage : ça m'empêchera de rechuter.
Là, c'est presque simple et finalement exact.
Tes liens vers les ACL et ACE m'avaient échappé.
Si le cur vous dit de continuer à aider l'auto-didacte cafouilleux que je suis à mettre de l'ordre dans ses connaissances disparates et inexactes : que valent ces axiomes ?
- Copier efface les ACL héritables, déplacer conserve POSIX-ACL héritables-ACL explicites.
- Archiver un fichier efface toutes ses ACL.
- Copier efface les ACL héritables, déplacer conserve POSIX-ACL héritables-ACL explicites.
- Archiver un fichier efface toutes ses ACL.
Bin... en fait, ça dépend... :rateau:
Il faudrait analyser ce qui se passe au niveau du Finder, qui correspond sans doute, dans ta question, implicitement à l'outil utilisé pour effectuer les opérations.
Mais, d'un autre côté, j'utilise (très) souvent d'autres outils, disponibles en mode texte et qui, eux, ont des options pour conserver (ou non) les différentes caractéristiques attachées aux fichiers (ressources diverses, droits, propriétaire/groupe etc.) lors des copies, déplacements ou archivages.
Je t'avouerais que je ne me suis jamais penché sérieusement sur la gestion des ACL sur Mac OS X, uniquement par à-coup quand le besoin se fait sentir (en plus, ça varie suivant les systèmes UNIX, Ouinedoze et tout ça...)
Il faudrait analyser ce qui se passe au niveau du Finder, qui correspond sans doute, dans ta question, implicitement à l'outil utilisé pour effectuer les opérations.
Mais, d'un autre côté, j'utilise (très) souvent d'autres outils, disponibles en mode texte et qui, eux, ont des options pour conserver (ou non) les différentes caractéristiques attachées aux fichiers (ressources diverses, droits, propriétaire/groupe etc.) lors des copies, déplacements ou archivages.
Je t'avouerais que je ne me suis jamais penché sérieusement sur la gestion des ACL sur Mac OS X, uniquement par à-coup quand le besoin se fait sentir (en plus, ça varie suivant les systèmes UNIX, Ouinedoze et tout ça...)
verifie le formatage du volume, sinon ton transfert peut coincer
( chez soft le tonic , ils ont un dmg water paragon , ca devrait aider , en bonus il y a genieau d'offert)
