> Je comprends pas pourquoi j'arrive pas a changer les > permissions sur un lien
Simplement parce que ce n'est pas possible ! Enfin, il me semble !
un lien n'a pas de permission, seulement la cible du lien
Klaus
fra-duf-no-spam
Le 12923ième jour après Epoch, Klaus Becker écrivait:
Le Vendredi 20 Mai 2005 21:08, Cyprien a écrit :
> Je comprends pas pourquoi j'arrive pas a changer les > permissions sur un lien
Simplement parce que ce n'est pas possible ! Enfin, il me semble !
un lien n'a pas de permission, seulement la cible du lien
Je confirme... extrait du man de ln:
Un lien symbolique est d'un tout autre genre. [...] Lorsque l'on accède à un lien symbolique (avec les appels systèmes open(2) ou stat(2)), le nom du lien symbolique est remplacé, par le noyau Unix, par une référence au fichier vers lequel le lien pointe. Toutefois, avec les appels rm(1) et unlink(2) le lien lui-même est supprimé, et non pas le fichier visé.
Par contre, là où je suis un peu choqué, c'est quand je vois les permissions de ses fichiers liens: "lrwxr-xr-x" alors qu'il me semble qu'en général, c'est "lrwxrwxrwx" ...
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Le 12923ième jour après Epoch,
Klaus Becker écrivait:
Le Vendredi 20 Mai 2005 21:08, Cyprien a écrit :
> Je comprends pas pourquoi j'arrive pas a changer les
> permissions sur un lien
Simplement parce que ce n'est pas possible !
Enfin, il me semble !
un lien n'a pas de permission, seulement la cible du lien
Je confirme... extrait du man de ln:
Un lien symbolique est d'un tout autre genre.
[...]
Lorsque l'on accède à un lien symbolique (avec les appels
systèmes open(2) ou stat(2)), le nom du lien symbolique est
remplacé, par le noyau Unix, par une référence au fichier
vers lequel le lien pointe. Toutefois, avec les appels
rm(1) et unlink(2) le lien lui-même est supprimé, et non pas le
fichier visé.
Par contre, là où je suis un peu choqué, c'est quand je vois les
permissions de ses fichiers liens: "lrwxr-xr-x" alors qu'il me semble
qu'en général, c'est "lrwxrwxrwx" ...
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Le 12923ième jour après Epoch, Klaus Becker écrivait:
Le Vendredi 20 Mai 2005 21:08, Cyprien a écrit :
> Je comprends pas pourquoi j'arrive pas a changer les > permissions sur un lien
Simplement parce que ce n'est pas possible ! Enfin, il me semble !
un lien n'a pas de permission, seulement la cible du lien
Je confirme... extrait du man de ln:
Un lien symbolique est d'un tout autre genre. [...] Lorsque l'on accède à un lien symbolique (avec les appels systèmes open(2) ou stat(2)), le nom du lien symbolique est remplacé, par le noyau Unix, par une référence au fichier vers lequel le lien pointe. Toutefois, avec les appels rm(1) et unlink(2) le lien lui-même est supprimé, et non pas le fichier visé.
Par contre, là où je suis un peu choqué, c'est quand je vois les permissions de ses fichiers liens: "lrwxr-xr-x" alors qu'il me semble qu'en général, c'est "lrwxrwxrwx" ...
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Debian User
> Un lien symbolique est d'un tout autre genre. [...] Lorsque l'on accède à un lien symbolique (avec les appels systèmes open(2) ou stat(2)), le nom du lien symbolique est remplacé, par le noyau Unix, par une référence au fichier vers lequel le lien pointe. Toutefois, avec les appels rm(1) et unlink(2) le lien lui-même est supprimé, et non pas le fichier visé.
J'avais compris que le lien était remplacé par le fichier cible.
cat /dev/modem = cat /dev/ttyS0 par exemple
Mais par contre qu'en est-il des permissions?
Et effectivement je comprendrais un peu mieux si les permissions du liens étaient toutes à rwxrwxrwx. Tout le monde pourrait rwx le lien mais une fois l'appel fait au lien se serait les permissions de la cible qui entrerait en jeu....
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
> Un lien symbolique est d'un tout autre genre.
[...]
Lorsque l'on accède à un lien symbolique (avec les appels
systèmes open(2) ou stat(2)), le nom du lien symbolique est
remplacé, par le noyau Unix, par une référence au fichier
vers lequel le lien pointe. Toutefois, avec les appels
rm(1) et unlink(2) le lien lui-même est supprimé, et non pas le
fichier visé.
J'avais compris que le lien était remplacé par le fichier cible.
cat /dev/modem = cat /dev/ttyS0 par exemple
Mais par contre qu'en est-il des permissions?
Et effectivement je comprendrais un peu mieux si les permissions du
liens étaient toutes à rwxrwxrwx. Tout le monde pourrait rwx le lien
mais une fois l'appel fait au lien se serait les permissions de la cible
qui entrerait en jeu....
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Un lien symbolique est d'un tout autre genre. [...] Lorsque l'on accède à un lien symbolique (avec les appels systèmes open(2) ou stat(2)), le nom du lien symbolique est remplacé, par le noyau Unix, par une référence au fichier vers lequel le lien pointe. Toutefois, avec les appels rm(1) et unlink(2) le lien lui-même est supprimé, et non pas le fichier visé.
J'avais compris que le lien était remplacé par le fichier cible.
cat /dev/modem = cat /dev/ttyS0 par exemple
Mais par contre qu'en est-il des permissions?
Et effectivement je comprendrais un peu mieux si les permissions du liens étaient toutes à rwxrwxrwx. Tout le monde pourrait rwx le lien mais une fois l'appel fait au lien se serait les permissions de la cible qui entrerait en jeu....
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Vincent Lefevre
On 2005-05-21 10:05:04 +0200, Debian User wrote:
Et effectivement je comprendrais un peu mieux si les permissions du liens étaient toutes à rwxrwxrwx.
C'est normalement le cas. Éventuellement, le "w" pourrait disparaître sur une partition en read-only?
Essaie de voir ce que tu obtiens au niveau des appels système...
> Essaie de voir ce que tu obtiens au niveau des appels système...
Hein? C'est quoi donc? Comment je fais-je?
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Vincent Lefevre
On 2005-05-22 23:59:07 +0200, Debian User wrote:
> Essaie de voir ce que tu obtiens au niveau des appels système...
Hein? C'est quoi donc? Comment je fais-je?
En fait, tu as déjà des front-end. Déjà, "ls -l" te donne ce qu'il faut, mais on ne sait jamais, il fait peut-être un traitement, et c'est pour ça qu'il peut être préférable d'obtenir le champ st_mode (qui donne le type du fichier et les permissions) directement.
Avec le stat de coreutils:
$ stat -c%f fichier
Avec le stat de zsh (module zsh/stat):
$ printf "%xn" `stat -L +mode fichier`
ou pour l'avoir en octal:
$ printf "%on" `stat -L +mode fichier`
Normalement, tu devrais obtenir a1ff (en hexa) ou 120777 (en octal).
La page man stat(2) te donne la signification:
S_IFLNK 0120000 symbolic link [...] S_IRWXU 00700 mask for file owner permissions S_IRUSR 00400 owner has read permission S_IWUSR 00200 owner has write permission S_IXUSR 00100 owner has execute permission S_IRWXG 00070 mask for group permissions S_IRGRP 00040 group has read permission S_IWGRP 00020 group has write permission S_IXGRP 00010 group has execute permission S_IRWXO 00007 mask for permissions for others (not in group) S_IROTH 00004 others have read permission S_IWOTH 00002 others have write permisson S_IXOTH 00001 others have execute permission
Maintenant, si c'est vraiment incorrect: pour corriger, c'est normal que tu n'y arrives pas avec chmod. La page man chmod(1) dit:
chmod never changes the permissions of symbolic links; the chmod system call cannot change their permissions. This is not a problem since the permissions of symbolic links are never used. However, for each sym- bolic link listed on the command line, chmod changes the permissions of the pointed-to file. In contrast, chmod ignores symbolic links encoun- tered during recursive directory traversals.
En revanche, l'appel système chmod modifie peut-être les permissions du lien symbolique. Dans ce cas, il faut que tu te fasses un petit programme C qui le fasse. Mais le plus simple est peut-être de faire un rm du lien symbolique et de recréer le lien avec "ln -s".
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
On 2005-05-22 23:59:07 +0200, Debian User wrote:
> Essaie de voir ce que tu obtiens au niveau des appels système...
Hein? C'est quoi donc? Comment je fais-je?
En fait, tu as déjà des front-end. Déjà, "ls -l" te donne ce qu'il
faut, mais on ne sait jamais, il fait peut-être un traitement, et
c'est pour ça qu'il peut être préférable d'obtenir le champ st_mode
(qui donne le type du fichier et les permissions) directement.
Avec le stat de coreutils:
$ stat -c%f fichier
Avec le stat de zsh (module zsh/stat):
$ printf "%xn" `stat -L +mode fichier`
ou pour l'avoir en octal:
$ printf "%on" `stat -L +mode fichier`
Normalement, tu devrais obtenir a1ff (en hexa) ou 120777 (en octal).
La page man stat(2) te donne la signification:
S_IFLNK 0120000 symbolic link
[...]
S_IRWXU 00700 mask for file owner permissions
S_IRUSR 00400 owner has read permission
S_IWUSR 00200 owner has write permission
S_IXUSR 00100 owner has execute permission
S_IRWXG 00070 mask for group permissions
S_IRGRP 00040 group has read permission
S_IWGRP 00020 group has write permission
S_IXGRP 00010 group has execute permission
S_IRWXO 00007 mask for permissions for others (not in group)
S_IROTH 00004 others have read permission
S_IWOTH 00002 others have write permisson
S_IXOTH 00001 others have execute permission
Maintenant, si c'est vraiment incorrect: pour corriger, c'est normal
que tu n'y arrives pas avec chmod. La page man chmod(1) dit:
chmod never changes the permissions of symbolic links; the chmod system
call cannot change their permissions. This is not a problem since the
permissions of symbolic links are never used. However, for each sym-
bolic link listed on the command line, chmod changes the permissions of
the pointed-to file. In contrast, chmod ignores symbolic links encoun-
tered during recursive directory traversals.
En revanche, l'appel système chmod modifie peut-être les permissions
du lien symbolique. Dans ce cas, il faut que tu te fasses un petit
programme C qui le fasse. Mais le plus simple est peut-être de faire
un rm du lien symbolique et de recréer le lien avec "ln -s".
> Essaie de voir ce que tu obtiens au niveau des appels système...
Hein? C'est quoi donc? Comment je fais-je?
En fait, tu as déjà des front-end. Déjà, "ls -l" te donne ce qu'il faut, mais on ne sait jamais, il fait peut-être un traitement, et c'est pour ça qu'il peut être préférable d'obtenir le champ st_mode (qui donne le type du fichier et les permissions) directement.
Avec le stat de coreutils:
$ stat -c%f fichier
Avec le stat de zsh (module zsh/stat):
$ printf "%xn" `stat -L +mode fichier`
ou pour l'avoir en octal:
$ printf "%on" `stat -L +mode fichier`
Normalement, tu devrais obtenir a1ff (en hexa) ou 120777 (en octal).
La page man stat(2) te donne la signification:
S_IFLNK 0120000 symbolic link [...] S_IRWXU 00700 mask for file owner permissions S_IRUSR 00400 owner has read permission S_IWUSR 00200 owner has write permission S_IXUSR 00100 owner has execute permission S_IRWXG 00070 mask for group permissions S_IRGRP 00040 group has read permission S_IWGRP 00020 group has write permission S_IXGRP 00010 group has execute permission S_IRWXO 00007 mask for permissions for others (not in group) S_IROTH 00004 others have read permission S_IWOTH 00002 others have write permisson S_IXOTH 00001 others have execute permission
Maintenant, si c'est vraiment incorrect: pour corriger, c'est normal que tu n'y arrives pas avec chmod. La page man chmod(1) dit:
chmod never changes the permissions of symbolic links; the chmod system call cannot change their permissions. This is not a problem since the permissions of symbolic links are never used. However, for each sym- bolic link listed on the command line, chmod changes the permissions of the pointed-to file. In contrast, chmod ignores symbolic links encoun- tered during recursive directory traversals.
En revanche, l'appel système chmod modifie peut-être les permissions du lien symbolique. Dans ce cas, il faut que tu te fasses un petit programme C qui le fasse. Mais le plus simple est peut-être de faire un rm du lien symbolique et de recréer le lien avec "ln -s".
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Vincent Lefevre
On 2005-05-21 01:24:41 +0200, François TOURDE wrote:
Le 12923ième jour après Epoch, Klaus Becker écrivait:
> Le Vendredi 20 Mai 2005 21:08, Cyprien a écrit : >> > Je comprends pas pourquoi j'arrive pas a changer les >> > permissions sur un lien >> >> Simplement parce que ce n'est pas possible ! >> Enfin, il me semble !
Avec la commande chmod(1), c'est vrai (cf mon dernier message). Avec l'appel système, c'est peut-être possible (pas essayé).
> un lien n'a pas de permission, seulement la cible du lien
Au niveau de l'appel système lstat, un lien a des permissions (c'est normalement 0777, mais que se passe-t-il en cas de corruption du système de fichier ou de bug du noyau qui les aurait changées?).
Je confirme... extrait du man de ln:
Un lien symbolique est d'un tout autre genre. [...] Lorsque l'on accède à un lien symbolique (avec les appels systèmes open(2) ou stat(2)), le nom du lien symbolique est remplacé, par le noyau Unix, par une référence au fichier vers lequel le lien pointe. Toutefois, avec les appels rm(1) et unlink(2) le lien lui-même est supprimé, et non pas le fichier visé.
En plus de stat(2), tu as lstat(2), qui fait un stat sur le lien lui-même et non pas sur le fichier pointé.
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
On 2005-05-21 01:24:41 +0200, François TOURDE wrote:
Le 12923ième jour après Epoch,
Klaus Becker écrivait:
> Le Vendredi 20 Mai 2005 21:08, Cyprien a écrit :
>> > Je comprends pas pourquoi j'arrive pas a changer les
>> > permissions sur un lien
>>
>> Simplement parce que ce n'est pas possible !
>> Enfin, il me semble !
Avec la commande chmod(1), c'est vrai (cf mon dernier message).
Avec l'appel système, c'est peut-être possible (pas essayé).
> un lien n'a pas de permission, seulement la cible du lien
Au niveau de l'appel système lstat, un lien a des permissions (c'est
normalement 0777, mais que se passe-t-il en cas de corruption du
système de fichier ou de bug du noyau qui les aurait changées?).
Je confirme... extrait du man de ln:
Un lien symbolique est d'un tout autre genre.
[...]
Lorsque l'on accède à un lien symbolique (avec les appels
systèmes open(2) ou stat(2)), le nom du lien symbolique est
remplacé, par le noyau Unix, par une référence au fichier
vers lequel le lien pointe. Toutefois, avec les appels
rm(1) et unlink(2) le lien lui-même est supprimé, et non pas le
fichier visé.
En plus de stat(2), tu as lstat(2), qui fait un stat sur le lien
lui-même et non pas sur le fichier pointé.
On 2005-05-21 01:24:41 +0200, François TOURDE wrote:
Le 12923ième jour après Epoch, Klaus Becker écrivait:
> Le Vendredi 20 Mai 2005 21:08, Cyprien a écrit : >> > Je comprends pas pourquoi j'arrive pas a changer les >> > permissions sur un lien >> >> Simplement parce que ce n'est pas possible ! >> Enfin, il me semble !
Avec la commande chmod(1), c'est vrai (cf mon dernier message). Avec l'appel système, c'est peut-être possible (pas essayé).
> un lien n'a pas de permission, seulement la cible du lien
Au niveau de l'appel système lstat, un lien a des permissions (c'est normalement 0777, mais que se passe-t-il en cas de corruption du système de fichier ou de bug du noyau qui les aurait changées?).
Je confirme... extrait du man de ln:
Un lien symbolique est d'un tout autre genre. [...] Lorsque l'on accède à un lien symbolique (avec les appels systèmes open(2) ou stat(2)), le nom du lien symbolique est remplacé, par le noyau Unix, par une référence au fichier vers lequel le lien pointe. Toutefois, avec les appels rm(1) et unlink(2) le lien lui-même est supprimé, et non pas le fichier visé.
En plus de stat(2), tu as lstat(2), qui fait un stat sur le lien lui-même et non pas sur le fichier pointé.
