Comment peut-on cacher un dossier dans Mac OS X 10.3.9. Rien de
disponible dans la fenêtre d'information du dossier. J'ai essayé de
créer un fichier .hidden dans le dossier au dessus avec le nom du
dossier devant : rien (même après redémarrage du Finder).
In article <1h7723e.wo58lo1ukowgcN%, (Nicolas MICHEL) wrote:
En faisant des tests, j'ai fait un chflags sappnd mondossier
et depuis même root ne peut pas l'effacer. Que faire ?
lire le man ...
Lequel, man chflags ? C'est fait. Et après ? Le man dit "SEE ALSO chflags(2)" or : ~> man 2 chflags No entry for chflags in section 2 of the manual
La section 2 ce sont les appels système. Il y a de forte chance que ça ne soit installé que si on installe les outils de développement.
-- Si vous embauchez, voici mon CV http://www.rail.eu.org/cv/cv.pdf
patpro ~ Patrick Proniewski
In article , patpro ~ Patrick Proniewski wrote:
bon alors en effet, ça marche pas. On peut placer le flag sappnd sur un fichier mais on ne peut pas le retirer. Par la suite ça empêche de supprimer le fichier, ou de le déplacer.
je devrais préciser : contrairement a FreeBSD, pour qui le flag peut se passer de 0 à 1 et 1 à 0 dès l'instant qu'on est root.
Je commence à me pencher sérieusement sur clri (clear inode) que je ferais suivre d'un reboot en single user avec fsck. Quelqu'un a-t-il une recette différente ?
finalement je me suis penché sur la manière douce : reboot single user, chflags nosappnd, et reboot.
Je suis tjrs intéressé par un avis sur la méthode clri, parce que pour faire mon test j'ai utilisé un de nos serveur en 10.3 (pas un en prod quand meme), et j'aimerai bien éviter le reboot.
patpro
In article <patpro-B06328.13445007122005@localhost>,
patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> wrote:
bon alors en effet, ça marche pas. On peut placer le flag sappnd sur un
fichier mais on ne peut pas le retirer. Par la suite ça empêche de
supprimer le fichier, ou de le déplacer.
je devrais préciser : contrairement a FreeBSD, pour qui le flag peut se
passer de 0 à 1 et 1 à 0 dès l'instant qu'on est root.
Je commence à me pencher sérieusement sur clri (clear inode) que je
ferais suivre d'un reboot en single user avec fsck.
Quelqu'un a-t-il une recette différente ?
finalement je me suis penché sur la manière douce : reboot single user,
chflags nosappnd, et reboot.
Je suis tjrs intéressé par un avis sur la méthode clri, parce que pour
faire mon test j'ai utilisé un de nos serveur en 10.3 (pas un en prod
quand meme), et j'aimerai bien éviter le reboot.
bon alors en effet, ça marche pas. On peut placer le flag sappnd sur un fichier mais on ne peut pas le retirer. Par la suite ça empêche de supprimer le fichier, ou de le déplacer.
je devrais préciser : contrairement a FreeBSD, pour qui le flag peut se passer de 0 à 1 et 1 à 0 dès l'instant qu'on est root.
Je commence à me pencher sérieusement sur clri (clear inode) que je ferais suivre d'un reboot en single user avec fsck. Quelqu'un a-t-il une recette différente ?
finalement je me suis penché sur la manière douce : reboot single user, chflags nosappnd, et reboot.
Je suis tjrs intéressé par un avis sur la méthode clri, parce que pour faire mon test j'ai utilisé un de nos serveur en 10.3 (pas un en prod quand meme), et j'aimerai bien éviter le reboot.
patpro
Nicolas.MICHEL
Patrick Stadelmann wrote:
Un flag c'est binaire : on ou off. Un attribut ça peut être plusieurs choix (e.g. la famille qui est un attribut de 3-bit).
Oui, mais à quoi bon avoir ces 2 éléments ? L'un vient d'unix et l'autre de classic ?
Et pourquoi ne corespondent-t-ils que dans un cas et pas dans les autres ? (parceque ouchg = L, et ça j'utilises souvent et ça fonctionne )
Enfin bon, c'est pas important. Mais c'est le genre d'incohérences qui m'ennervent. -- S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes iChat/AIM : michelnicolas
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
Un flag c'est binaire : on ou off. Un attribut ça peut être plusieurs
choix (e.g. la famille qui est un attribut de 3-bit).
Oui, mais à quoi bon avoir ces 2 éléments ?
L'un vient d'unix et l'autre de classic ?
Et pourquoi ne corespondent-t-ils que dans un cas et pas dans les autres
?
(parceque ouchg = L, et ça j'utilises souvent et ça fonctionne )
Enfin bon, c'est pas important.
Mais c'est le genre d'incohérences qui m'ennervent.
--
S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes
iChat/AIM : michelnicolas
Un flag c'est binaire : on ou off. Un attribut ça peut être plusieurs choix (e.g. la famille qui est un attribut de 3-bit).
Oui, mais à quoi bon avoir ces 2 éléments ? L'un vient d'unix et l'autre de classic ?
Et pourquoi ne corespondent-t-ils que dans un cas et pas dans les autres ? (parceque ouchg = L, et ça j'utilises souvent et ça fonctionne )
Enfin bon, c'est pas important. Mais c'est le genre d'incohérences qui m'ennervent. -- S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes iChat/AIM : michelnicolas
patpro ~ Patrick Proniewski
bon,
apres quelques recherches, ce comportement de MacOS X est normal, c'est du au fait que le kernel.securelevel est à 1 en utilisation normale. Il doit être à 0 pour pouvoir changer les flags de fichiers s*.
patpro
bon,
apres quelques recherches, ce comportement de MacOS X est normal, c'est
du au fait que le kernel.securelevel est à 1 en utilisation normale. Il
doit être à 0 pour pouvoir changer les flags de fichiers s*.
apres quelques recherches, ce comportement de MacOS X est normal, c'est du au fait que le kernel.securelevel est à 1 en utilisation normale. Il doit être à 0 pour pouvoir changer les flags de fichiers s*.
patpro
Patrick Stadelmann
In article <1h778b9.1395aw11qfdeqyN%, (Nicolas MICHEL) wrote:
Patrick Stadelmann wrote:
Un flag c'est binaire : on ou off. Un attribut ça peut être plusieurs choix (e.g. la famille qui est un attribut de 3-bit).
Oui, mais à quoi bon avoir ces 2 éléments ? L'un vient d'unix et l'autre de classic ?
Les attributs (ceux que l'on manipule avec SetFile) sont liés à HFS. Note que dans la doc technique, Apple utilise également le terme "flag". Les attributs verrouillé, invisible ... sont ainsi stocké dans le catalogue HFS+ dans un champs qui s'appelle "fdFlags" (fd pour Finder).
Les flags utilisés par chflags eux viennent de Unix. Dans le catalogue HFS+, ils sont stockés dans les champs ownerFlags et adminFlags.
Et pourquoi ne corespondent-t-ils que dans un cas et pas dans les autres ? (parceque ouchg = L, et ça j'utilises souvent et ça fonctionne )
Oui, mais c'est le seul cas je crois. Et dans le catalogue, ça reste deux champs séparés, mais Mac OS X les traite comme équivalent, et la modification de l'un se répercute sur l'autre. Pourquoi que ces deux ? Je ne sais pas. Peut-être que c'est le seul cas où le sens Unix et HFS était suffisamment proche. Pour "opaque", la technote sur HFS+ décrit son usage et en effet ça n'est pas le même que "invisible" de HFS.
In article <1h778b9.1395aw11qfdeqyN%Nicolas.MICHEL@BonBon.net>,
Nicolas.MICHEL@BonBon.net (Nicolas MICHEL) wrote:
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
Un flag c'est binaire : on ou off. Un attribut ça peut être plusieurs
choix (e.g. la famille qui est un attribut de 3-bit).
Oui, mais à quoi bon avoir ces 2 éléments ?
L'un vient d'unix et l'autre de classic ?
Les attributs (ceux que l'on manipule avec SetFile) sont liés à HFS.
Note que dans la doc technique, Apple utilise également le terme "flag".
Les attributs verrouillé, invisible ... sont ainsi stocké dans le
catalogue HFS+ dans un champs qui s'appelle "fdFlags" (fd pour Finder).
Les flags utilisés par chflags eux viennent de Unix. Dans le catalogue
HFS+, ils sont stockés dans les champs ownerFlags et adminFlags.
Et pourquoi ne corespondent-t-ils que dans un cas et pas dans les autres
?
(parceque ouchg = L, et ça j'utilises souvent et ça fonctionne )
Oui, mais c'est le seul cas je crois. Et dans le catalogue, ça reste
deux champs séparés, mais Mac OS X les traite comme équivalent, et la
modification de l'un se répercute sur l'autre. Pourquoi que ces deux ?
Je ne sais pas. Peut-être que c'est le seul cas où le sens Unix et HFS
était suffisamment proche. Pour "opaque", la technote sur HFS+ décrit
son usage et en effet ça n'est pas le même que "invisible" de HFS.
In article <1h778b9.1395aw11qfdeqyN%, (Nicolas MICHEL) wrote:
Patrick Stadelmann wrote:
Un flag c'est binaire : on ou off. Un attribut ça peut être plusieurs choix (e.g. la famille qui est un attribut de 3-bit).
Oui, mais à quoi bon avoir ces 2 éléments ? L'un vient d'unix et l'autre de classic ?
Les attributs (ceux que l'on manipule avec SetFile) sont liés à HFS. Note que dans la doc technique, Apple utilise également le terme "flag". Les attributs verrouillé, invisible ... sont ainsi stocké dans le catalogue HFS+ dans un champs qui s'appelle "fdFlags" (fd pour Finder).
Les flags utilisés par chflags eux viennent de Unix. Dans le catalogue HFS+, ils sont stockés dans les champs ownerFlags et adminFlags.
Et pourquoi ne corespondent-t-ils que dans un cas et pas dans les autres ? (parceque ouchg = L, et ça j'utilises souvent et ça fonctionne )
Oui, mais c'est le seul cas je crois. Et dans le catalogue, ça reste deux champs séparés, mais Mac OS X les traite comme équivalent, et la modification de l'un se répercute sur l'autre. Pourquoi que ces deux ? Je ne sais pas. Peut-être que c'est le seul cas où le sens Unix et HFS était suffisamment proche. Pour "opaque", la technote sur HFS+ décrit son usage et en effet ça n'est pas le même que "invisible" de HFS.
La section 2 ce sont les appels système. Il y a de forte chance que ça ne soit installé que si on installe les outils de développement.
Je les ai, les outils dev. Bon, pas grave, il est sur le web.
-- S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes iChat/AIM : michelnicolas
Nicolas.MICHEL
patpro ~ Patrick Proniewski wrote:
finalement je me suis penché sur la manière douce : reboot single user, chflags nosappnd, et reboot.
Merci pour la soluce ! J'y avais pas pensé du tout.
Reste que c'est quand-même balèze, ce flag. Je me demande dans quel cas on peut l'utiliser... Su un dossier par exemple, root peut ajouter des fichiers mais pas les effacer...
Bon, arrivera un jour où j'en aurai besoins, mais pour l'heure c'est juste rigolo. -- S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes iChat/AIM : michelnicolas
patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> wrote:
finalement je me suis penché sur la manière douce : reboot single user,
chflags nosappnd, et reboot.
Merci pour la soluce !
J'y avais pas pensé du tout.
Reste que c'est quand-même balèze, ce flag.
Je me demande dans quel cas on peut l'utiliser...
Su un dossier par exemple, root peut ajouter des fichiers mais pas les
effacer...
Bon, arrivera un jour où j'en aurai besoins, mais pour l'heure c'est
juste rigolo.
--
S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes
iChat/AIM : michelnicolas
finalement je me suis penché sur la manière douce : reboot single user, chflags nosappnd, et reboot.
Merci pour la soluce ! J'y avais pas pensé du tout.
Reste que c'est quand-même balèze, ce flag. Je me demande dans quel cas on peut l'utiliser... Su un dossier par exemple, root peut ajouter des fichiers mais pas les effacer...
Bon, arrivera un jour où j'en aurai besoins, mais pour l'heure c'est juste rigolo. -- S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes iChat/AIM : michelnicolas
