entre deux bécannes sous Xubuntu, j'essaie de copier la clé publique de
l'un sur l'autre, basique me direz vous...
MAIS ça coince :
yt@ubuntu:~$ ssh-copy-id -i ~/.ssh/id_dsa.pub mfj@Gericom
mfj@<son adresse IPV6>'s password:
cat: erreur d'écriture: Aucun espace disponible sur le périphérique
du coup, je me tourne vers scp :
yt@ubuntu:~/.ssh$ scp id_dsa.pub mfj@Gericom:/home/mfj/Bureau/cle_yvon.pub
mfj@<son adresse IPV6>'s password:
id_dsa.pub
100% 599
0.6KB/s 00:00
scp: /home/mfj/Bureau/cle_yvon.pub: No space left on device
Étrange non ? il me reste qd même 9Go sur la partoche Xubuntu...
effectivement, quand je regarde par ssh le contenu du fichier
téléchargé, il est vide :
yt@ubuntu:~/.ssh$ ssh mfj@Gericom
mfj@<son adresse IPV6>'s password:
Welcome to Ubuntu 11.10 (GNU/Linux 3.0.0-14-generic i686)
* Documentation: https://help.ubuntu.com/
Last login: Wed Nov 30 13:21:51 2011 from
<mon adresse IPV6>
mfj@GERICOM:~$ ls Bureau
cle_yvon.pub
mfj@GERICOM:~$ cat Bureau/cle_yvon.pub
mfj@GERICOM:~$
"denis.paris" , dans le message <4ed7bab2$0$25933$, a écrit :
Perso je monte /tmp et /var/tmp en RAM et je n'ai jamais constaté d'instabilité.
Tu fais ce que tu veux avec ta machine, hein. Tu n'es juste pas conforme aux usages recommandés. Si tu as envie d'appeler le compte d'UID 0 papa et de mettre les fichier de configuration dans /bonjour, rien ne te l'interdit non plus.
J'en suis conscient, j'aurais pu me dispenser de ce commentaire personnel, ta remarque est justifiée mais tu ne réponds pas sur le fond de mon message, qui est centré sur la fréquence des purges des répertoires /tmp et /var/tmp.
Le 01/12/2011 18:51, Nicolas George a écrit :
"denis.paris" , dans le message
<4ed7bab2$0$25933$426a34cc@news.free.fr>, a écrit :
Perso je monte /tmp et /var/tmp en RAM et je n'ai jamais constaté
d'instabilité.
Tu fais ce que tu veux avec ta machine, hein. Tu n'es juste pas conforme aux
usages recommandés. Si tu as envie d'appeler le compte d'UID 0 papa et de
mettre les fichier de configuration dans /bonjour, rien ne te l'interdit non
plus.
J'en suis conscient, j'aurais pu me dispenser de ce commentaire
personnel, ta remarque est justifiée mais tu ne réponds pas sur le fond
de mon message, qui est centré sur la fréquence des purges des
répertoires /tmp et /var/tmp.
"denis.paris" , dans le message <4ed7bab2$0$25933$, a écrit :
Perso je monte /tmp et /var/tmp en RAM et je n'ai jamais constaté d'instabilité.
Tu fais ce que tu veux avec ta machine, hein. Tu n'es juste pas conforme aux usages recommandés. Si tu as envie d'appeler le compte d'UID 0 papa et de mettre les fichier de configuration dans /bonjour, rien ne te l'interdit non plus.
J'en suis conscient, j'aurais pu me dispenser de ce commentaire personnel, ta remarque est justifiée mais tu ne réponds pas sur le fond de mon message, qui est centré sur la fréquence des purges des répertoires /tmp et /var/tmp.
Nicolas George
"denis.paris" , dans le message <4ed7c176$0$8826$, a écrit :
qui est centré sur la fréquence des purges des répertoires /tmp et /var/tmp.
J'y avais répondu, et je t'invite à relire la première phrase de la norme que j'ai citée :
« The /var/tmp directory is made available for programs that require temporary files or directories that are preserved between system reboots. »
Pour faire une analogie :
« Cette consigne est offerte aux voyageurs qui veulent entreposer leurs bagages pendant plusieurs jours. Les casiers sont vidés, et leur contenu détruit, toutes les nuits. »
Tu ne vois pas comme un bug ?
"denis.paris" , dans le message <4ed7c176$0$8826$426a34cc@news.free.fr>,
a écrit :
qui est centré sur la fréquence des purges des
répertoires /tmp et /var/tmp.
J'y avais répondu, et je t'invite à relire la première phrase de la norme
que j'ai citée :
« The /var/tmp directory is made available for programs that require
temporary files or directories that are preserved between system reboots. »
Pour faire une analogie :
« Cette consigne est offerte aux voyageurs qui veulent entreposer leurs
bagages pendant plusieurs jours. Les casiers sont vidés, et leur contenu
détruit, toutes les nuits. »
"denis.paris" , dans le message <4ed7c176$0$8826$, a écrit :
qui est centré sur la fréquence des purges des répertoires /tmp et /var/tmp.
J'y avais répondu, et je t'invite à relire la première phrase de la norme que j'ai citée :
« The /var/tmp directory is made available for programs that require temporary files or directories that are preserved between system reboots. »
Pour faire une analogie :
« Cette consigne est offerte aux voyageurs qui veulent entreposer leurs bagages pendant plusieurs jours. Les casiers sont vidés, et leur contenu détruit, toutes les nuits. »
Tu ne vois pas comme un bug ?
denis.paris
Le 01/12/2011 19:39, Nicolas George a écrit :
"denis.paris" , dans le message<4ed7c176$0$8826$, a écrit :
qui est centré sur la fréquence des purges des répertoires /tmp et /var/tmp.
J'y avais répondu, et je t'invite à relire la première phrase de la norme que j'ai citée :
« The /var/tmp directory is made available for programs that require temporary files or directories that are preserved between system reboots. »
Pour faire une analogie :
« Cette consigne est offerte aux voyageurs qui veulent entreposer leurs bagages pendant plusieurs jours. Les casiers sont vidés, et leur contenu détruit, toutes les nuits. »
Tu ne vois pas comme un bug ?
Même si elles ont parfois un rôle pédagogique indéniable, je me méfie des analogies: comparaison n'est pas raison.
Quand on dit "it is recommended that deletions occur at a less frequent interval than /tmp" on admet que la purge est possible. Donc qu'un programme pourrait potentiellement être gêné s'il s'attend à trouver des fichiers dans /var/tmp au reboot.
Si un tel programme existe, il reste à trouver. Si c'est dans le noyau, peut-être que les personnes dont les sources sont le livre de chevet pourraient trancher?
Le 01/12/2011 19:39, Nicolas George a écrit :
"denis.paris" , dans le message<4ed7c176$0$8826$426a34cc@news.free.fr>,
a écrit :
qui est centré sur la fréquence des purges des
répertoires /tmp et /var/tmp.
J'y avais répondu, et je t'invite à relire la première phrase de la norme
que j'ai citée :
« The /var/tmp directory is made available for programs that require
temporary files or directories that are preserved between system reboots. »
Pour faire une analogie :
« Cette consigne est offerte aux voyageurs qui veulent entreposer leurs
bagages pendant plusieurs jours. Les casiers sont vidés, et leur contenu
détruit, toutes les nuits. »
Tu ne vois pas comme un bug ?
Même si elles ont parfois un rôle pédagogique indéniable, je me méfie
des analogies: comparaison n'est pas raison.
Quand on dit "it is recommended that deletions occur at a less frequent
interval than /tmp" on admet que la purge est possible. Donc qu'un
programme pourrait potentiellement être gêné s'il s'attend à trouver des
fichiers dans /var/tmp au reboot.
Si un tel programme existe, il reste à trouver. Si c'est dans le noyau,
peut-être que les personnes dont les sources sont le livre de chevet
pourraient trancher?
"denis.paris" , dans le message<4ed7c176$0$8826$, a écrit :
qui est centré sur la fréquence des purges des répertoires /tmp et /var/tmp.
J'y avais répondu, et je t'invite à relire la première phrase de la norme que j'ai citée :
« The /var/tmp directory is made available for programs that require temporary files or directories that are preserved between system reboots. »
Pour faire une analogie :
« Cette consigne est offerte aux voyageurs qui veulent entreposer leurs bagages pendant plusieurs jours. Les casiers sont vidés, et leur contenu détruit, toutes les nuits. »
Tu ne vois pas comme un bug ?
Même si elles ont parfois un rôle pédagogique indéniable, je me méfie des analogies: comparaison n'est pas raison.
Quand on dit "it is recommended that deletions occur at a less frequent interval than /tmp" on admet que la purge est possible. Donc qu'un programme pourrait potentiellement être gêné s'il s'attend à trouver des fichiers dans /var/tmp au reboot.
Si un tel programme existe, il reste à trouver. Si c'est dans le noyau, peut-être que les personnes dont les sources sont le livre de chevet pourraient trancher?
Nicolas George
"denis.paris" , dans le message <4ed7dc15$0$25006$, a écrit :
Quand on dit "it is recommended that deletions occur at a less frequent interval than /tmp" on admet que la purge est possible. Donc qu'un programme pourrait potentiellement être gêné s'il s'attend à trouver des fichiers dans /var/tmp au reboot.
Il est évident, si on réfléchit deux secondes, qu'un programme ne peut compter avec certitude qu'un fichier soit toujours dans un répertoire temporaire, après quelque durée que ce soit.
Il n'en est pas moins vrai que si tu décides de purger /var/tmp au reboot, ou toutes les cinq minutes, tu es en contradiction avec l'usage recommandé, et dès lors tu ne dois pas venir te plaindre si, au hasard, un programme bouffe dix fois plus de bande passante qu'il ne devrait à retélécharger des fichiers qu'il s'attend à avoir laissé là.
"denis.paris" , dans le message
<4ed7dc15$0$25006$426a74cc@news.free.fr>, a écrit :
Quand on dit "it is recommended that deletions occur at a less frequent
interval than /tmp" on admet que la purge est possible. Donc qu'un
programme pourrait potentiellement être gêné s'il s'attend à trouver des
fichiers dans /var/tmp au reboot.
Il est évident, si on réfléchit deux secondes, qu'un programme ne peut
compter avec certitude qu'un fichier soit toujours dans un répertoire
temporaire, après quelque durée que ce soit.
Il n'en est pas moins vrai que si tu décides de purger /var/tmp au reboot,
ou toutes les cinq minutes, tu es en contradiction avec l'usage recommandé,
et dès lors tu ne dois pas venir te plaindre si, au hasard, un programme
bouffe dix fois plus de bande passante qu'il ne devrait à retélécharger des
fichiers qu'il s'attend à avoir laissé là.
"denis.paris" , dans le message <4ed7dc15$0$25006$, a écrit :
Quand on dit "it is recommended that deletions occur at a less frequent interval than /tmp" on admet que la purge est possible. Donc qu'un programme pourrait potentiellement être gêné s'il s'attend à trouver des fichiers dans /var/tmp au reboot.
Il est évident, si on réfléchit deux secondes, qu'un programme ne peut compter avec certitude qu'un fichier soit toujours dans un répertoire temporaire, après quelque durée que ce soit.
Il n'en est pas moins vrai que si tu décides de purger /var/tmp au reboot, ou toutes les cinq minutes, tu es en contradiction avec l'usage recommandé, et dès lors tu ne dois pas venir te plaindre si, au hasard, un programme bouffe dix fois plus de bande passante qu'il ne devrait à retélécharger des fichiers qu'il s'attend à avoir laissé là.
denis.paris
Le 01/12/2011 21:57, Nicolas George a écrit :
"denis.paris" , dans le message <4ed7dc15$0$25006$, a écrit :
Quand on dit "it is recommended that deletions occur at a less frequent interval than /tmp" on admet que la purge est possible. Donc qu'un programme pourrait potentiellement être gêné s'il s'attend à trouver des fichiers dans /var/tmp au reboot.
Il est évident, si on réfléchit deux secondes, qu'un programme ne peut compter avec certitude qu'un fichier soit toujours dans un répertoire temporaire, après quelque durée que ce soit.
J'en avais pris au moins dix pour arriver à la même conclusion: mon esprit est beaucoup moins rapide que le tiens, je l'admets volontiers.
Il n'en est pas moins vrai que si tu décides de purger /var/tmp au reboot, ou toutes les cinq minutes, tu es en contradiction avec l'usage recommandé, et dès lors tu ne dois pas venir te plaindre si, au hasard, un programme bouffe dix fois plus de bande passante qu'il ne devrait à retélécharger des fichiers qu'il s'attend à avoir laissé là.
Mais je ne me plains pas, je me contente d'observer que sur mon système, donc dans un cas particuliers (Ubuntu 10.04), /var/tmp reste constamment vide (excepté mon cache firefox), tandis que /tmp se remplit progressivement de fichiers utiles au fonctionnement du système, qui sont purgés au démarrage puisqu'il est en RAM.
Pour conclure en allant un peu dans ton sens je dirais que je m'autorise sur une machine personnelle des choses que je ne ferais pas en environnement professionnel sur un serveur de production, à moins d'avoir une très bonne raison de le faire.
Le 01/12/2011 21:57, Nicolas George a écrit :
"denis.paris" , dans le message
<4ed7dc15$0$25006$426a74cc@news.free.fr>, a écrit :
Quand on dit "it is recommended that deletions occur at a less frequent
interval than /tmp" on admet que la purge est possible. Donc qu'un
programme pourrait potentiellement être gêné s'il s'attend à trouver des
fichiers dans /var/tmp au reboot.
Il est évident, si on réfléchit deux secondes, qu'un programme ne peut
compter avec certitude qu'un fichier soit toujours dans un répertoire
temporaire, après quelque durée que ce soit.
J'en avais pris au moins dix pour arriver à la même conclusion: mon
esprit est beaucoup moins rapide que le tiens, je l'admets volontiers.
Il n'en est pas moins vrai que si tu décides de purger /var/tmp au reboot,
ou toutes les cinq minutes, tu es en contradiction avec l'usage recommandé,
et dès lors tu ne dois pas venir te plaindre si, au hasard, un programme
bouffe dix fois plus de bande passante qu'il ne devrait à retélécharger des
fichiers qu'il s'attend à avoir laissé là.
Mais je ne me plains pas, je me contente d'observer que sur mon système,
donc dans un cas particuliers (Ubuntu 10.04), /var/tmp reste constamment
vide (excepté mon cache firefox), tandis que /tmp se remplit
progressivement de fichiers utiles au fonctionnement du système, qui
sont purgés au démarrage puisqu'il est en RAM.
Pour conclure en allant un peu dans ton sens je dirais que je m'autorise
sur une machine personnelle des choses que je ne ferais pas en
environnement professionnel sur un serveur de production, à moins
d'avoir une très bonne raison de le faire.
"denis.paris" , dans le message <4ed7dc15$0$25006$, a écrit :
Quand on dit "it is recommended that deletions occur at a less frequent interval than /tmp" on admet que la purge est possible. Donc qu'un programme pourrait potentiellement être gêné s'il s'attend à trouver des fichiers dans /var/tmp au reboot.
Il est évident, si on réfléchit deux secondes, qu'un programme ne peut compter avec certitude qu'un fichier soit toujours dans un répertoire temporaire, après quelque durée que ce soit.
J'en avais pris au moins dix pour arriver à la même conclusion: mon esprit est beaucoup moins rapide que le tiens, je l'admets volontiers.
Il n'en est pas moins vrai que si tu décides de purger /var/tmp au reboot, ou toutes les cinq minutes, tu es en contradiction avec l'usage recommandé, et dès lors tu ne dois pas venir te plaindre si, au hasard, un programme bouffe dix fois plus de bande passante qu'il ne devrait à retélécharger des fichiers qu'il s'attend à avoir laissé là.
Mais je ne me plains pas, je me contente d'observer que sur mon système, donc dans un cas particuliers (Ubuntu 10.04), /var/tmp reste constamment vide (excepté mon cache firefox), tandis que /tmp se remplit progressivement de fichiers utiles au fonctionnement du système, qui sont purgés au démarrage puisqu'il est en RAM.
Pour conclure en allant un peu dans ton sens je dirais que je m'autorise sur une machine personnelle des choses que je ne ferais pas en environnement professionnel sur un serveur de production, à moins d'avoir une très bonne raison de le faire.
Benoit Izac
Bonjour,
le 01/12/2011 à 20:57, denis paris a écrit dans le message <4ed7dc15$0$25006$ :
Si un tel programme existe, il reste à trouver. Si c'est dans le noyau, peut-être que les personnes dont les sources sont le livre de chevet pourraient trancher?
Il me semble que certaine versions de vi laissent les fichiers de sauvegarde dans /var/tmp/vi. Tu peux comprendre aisément que si la machine crash, et que tu viens de taper un long message/code/... dans ton éditeur, tu es content lorsque tu redémarres la machine que le fichier soit partiellement récupérable. En effaçant /var/tmp, tu ne te laisses aucune chance.
La différence aussi c'est que vi va te demander si tu veux récupérer le fichier et une fois que tu l'auras enregistré, il supprimera le fichier qui n'a plus lieu d'être ; c'est l'application qui fait le ménage.
Il me semble aussi que gentoo l'utilisait pour portage (bon ça doit faire deux ans que je n'y ai pas touché donc je peux me tromper...).
-- Benoit Izac
Bonjour,
le 01/12/2011 à 20:57, denis paris a écrit dans le message
<4ed7dc15$0$25006$426a74cc@news.free.fr> :
Si un tel programme existe, il reste à trouver. Si c'est dans le
noyau, peut-être que les personnes dont les sources sont le livre de
chevet pourraient trancher?
Il me semble que certaine versions de vi laissent les fichiers de
sauvegarde dans /var/tmp/vi. Tu peux comprendre aisément que si la
machine crash, et que tu viens de taper un long message/code/... dans
ton éditeur, tu es content lorsque tu redémarres la machine que le
fichier soit partiellement récupérable. En effaçant /var/tmp, tu ne te
laisses aucune chance.
La différence aussi c'est que vi va te demander si tu veux récupérer le
fichier et une fois que tu l'auras enregistré, il supprimera le fichier
qui n'a plus lieu d'être ; c'est l'application qui fait le ménage.
Il me semble aussi que gentoo l'utilisait pour portage (bon ça doit
faire deux ans que je n'y ai pas touché donc je peux me tromper...).
le 01/12/2011 à 20:57, denis paris a écrit dans le message <4ed7dc15$0$25006$ :
Si un tel programme existe, il reste à trouver. Si c'est dans le noyau, peut-être que les personnes dont les sources sont le livre de chevet pourraient trancher?
Il me semble que certaine versions de vi laissent les fichiers de sauvegarde dans /var/tmp/vi. Tu peux comprendre aisément que si la machine crash, et que tu viens de taper un long message/code/... dans ton éditeur, tu es content lorsque tu redémarres la machine que le fichier soit partiellement récupérable. En effaçant /var/tmp, tu ne te laisses aucune chance.
La différence aussi c'est que vi va te demander si tu veux récupérer le fichier et une fois que tu l'auras enregistré, il supprimera le fichier qui n'a plus lieu d'être ; c'est l'application qui fait le ménage.
Il me semble aussi que gentoo l'utilisait pour portage (bon ça doit faire deux ans que je n'y ai pas touché donc je peux me tromper...).
-- Benoit Izac
denis.paris
Le 01/12/2011 23:32, Benoit Izac a écrit :
Bonjour,
le 01/12/2011 à 20:57, denis paris a écrit dans le message <4ed7dc15$0$25006$ :
Si un tel programme existe, il reste à trouver. Si c'est dans le noyau, peut-être que les personnes dont les sources sont le livre de chevet pourraient trancher?
Il me semble que certaine versions de vi laissent les fichiers de sauvegarde dans /var/tmp/vi. Tu peux comprendre aisément que si la machine crash, et que tu viens de taper un long message/code/... dans ton éditeur, tu es content lorsque tu redémarres la machine que le fichier soit partiellement récupérable. En effaçant /var/tmp, tu ne te laisses aucune chance.
La différence aussi c'est que vi va te demander si tu veux récupérer le fichier et une fois que tu l'auras enregistré, il supprimera le fichier qui n'a plus lieu d'être ; c'est l'application qui fait le ménage.
Il me semble aussi que gentoo l'utilisait pour portage (bon ça doit faire deux ans que je n'y ai pas touché donc je peux me tromper...).
OK, mais sur mon système (je viens de tester) vi créé un fichier .monfichier.swp dans le même répertoire que le fichier en cours d'édition, et propose de le récupérer en cas de crash (j'ai testé aussi: un kill de vi dans une autre fenêtre). et ce comportement me paraît très logique puisqu'on a forcément le droit d'écrire dans le répertoire du fichier que l'on édite.
Le 01/12/2011 23:32, Benoit Izac a écrit :
Bonjour,
le 01/12/2011 à 20:57, denis paris a écrit dans le message
<4ed7dc15$0$25006$426a74cc@news.free.fr> :
Si un tel programme existe, il reste à trouver. Si c'est dans le
noyau, peut-être que les personnes dont les sources sont le livre de
chevet pourraient trancher?
Il me semble que certaine versions de vi laissent les fichiers de
sauvegarde dans /var/tmp/vi. Tu peux comprendre aisément que si la
machine crash, et que tu viens de taper un long message/code/... dans
ton éditeur, tu es content lorsque tu redémarres la machine que le
fichier soit partiellement récupérable. En effaçant /var/tmp, tu ne te
laisses aucune chance.
La différence aussi c'est que vi va te demander si tu veux récupérer le
fichier et une fois que tu l'auras enregistré, il supprimera le fichier
qui n'a plus lieu d'être ; c'est l'application qui fait le ménage.
Il me semble aussi que gentoo l'utilisait pour portage (bon ça doit
faire deux ans que je n'y ai pas touché donc je peux me tromper...).
OK, mais sur mon système (je viens de tester) vi créé un fichier
.monfichier.swp dans le même répertoire que le fichier en cours
d'édition, et propose de le récupérer en cas de crash (j'ai testé aussi:
un kill de vi dans une autre fenêtre). et ce comportement me paraît très
logique puisqu'on a forcément le droit d'écrire dans le répertoire du
fichier que l'on édite.
le 01/12/2011 à 20:57, denis paris a écrit dans le message <4ed7dc15$0$25006$ :
Si un tel programme existe, il reste à trouver. Si c'est dans le noyau, peut-être que les personnes dont les sources sont le livre de chevet pourraient trancher?
Il me semble que certaine versions de vi laissent les fichiers de sauvegarde dans /var/tmp/vi. Tu peux comprendre aisément que si la machine crash, et que tu viens de taper un long message/code/... dans ton éditeur, tu es content lorsque tu redémarres la machine que le fichier soit partiellement récupérable. En effaçant /var/tmp, tu ne te laisses aucune chance.
La différence aussi c'est que vi va te demander si tu veux récupérer le fichier et une fois que tu l'auras enregistré, il supprimera le fichier qui n'a plus lieu d'être ; c'est l'application qui fait le ménage.
Il me semble aussi que gentoo l'utilisait pour portage (bon ça doit faire deux ans que je n'y ai pas touché donc je peux me tromper...).
OK, mais sur mon système (je viens de tester) vi créé un fichier .monfichier.swp dans le même répertoire que le fichier en cours d'édition, et propose de le récupérer en cas de crash (j'ai testé aussi: un kill de vi dans une autre fenêtre). et ce comportement me paraît très logique puisqu'on a forcément le droit d'écrire dans le répertoire du fichier que l'on édite.
Benoit Izac
Bonjour,
le 01/12/2011 à 23:46, denis paris a écrit dans le message <4ed803cc$0$25952$ :
OK, mais sur mon système (je viens de tester) vi créé un fichier .monfichier.swp dans le même répertoire que le fichier en cours d'édition, et propose de le récupérer en cas de crash (j'ai testé aussi: un kill de vi dans une autre fenêtre). et ce comportement me paraît très logique puisqu'on a forcément le droit d'écrire dans le répertoire du fichier que l'on édite.
C'est faux !
** root # mkdir -m751 /tmp/test_00 # cd /tmp/test_00 # touch a; chmod 666 a
** user % cd /tmp/test_00 % touch b touch: cannot touch `b': Permission denied % vi a % cat a coucou
-- Benoit Izac
Bonjour,
le 01/12/2011 à 23:46, denis paris a écrit dans le message
<4ed803cc$0$25952$426a74cc@news.free.fr> :
OK, mais sur mon système (je viens de tester) vi créé un fichier
.monfichier.swp dans le même répertoire que le fichier en cours
d'édition, et propose de le récupérer en cas de crash (j'ai testé
aussi: un kill de vi dans une autre fenêtre). et ce comportement me
paraît très logique puisqu'on a forcément le droit d'écrire dans le
répertoire du fichier que l'on édite.
C'est faux !
** root
# mkdir -m751 /tmp/test_00
# cd /tmp/test_00
# touch a; chmod 666 a
** user
% cd /tmp/test_00
% touch b
touch: cannot touch `b': Permission denied
% vi a
% cat a
coucou
le 01/12/2011 à 23:46, denis paris a écrit dans le message <4ed803cc$0$25952$ :
OK, mais sur mon système (je viens de tester) vi créé un fichier .monfichier.swp dans le même répertoire que le fichier en cours d'édition, et propose de le récupérer en cas de crash (j'ai testé aussi: un kill de vi dans une autre fenêtre). et ce comportement me paraît très logique puisqu'on a forcément le droit d'écrire dans le répertoire du fichier que l'on édite.
C'est faux !
** root # mkdir -m751 /tmp/test_00 # cd /tmp/test_00 # touch a; chmod 666 a
** user % cd /tmp/test_00 % touch b touch: cannot touch `b': Permission denied % vi a % cat a coucou
-- Benoit Izac
denis.paris
Le 01/12/2011 23:53, Benoit Izac a écrit :
Bonjour,
le 01/12/2011 à 23:46, denis paris a écrit dans le message <4ed803cc$0$25952$ :
OK, mais sur mon système (je viens de tester) vi créé un fichier .monfichier.swp dans le même répertoire que le fichier en cours d'édition, et propose de le récupérer en cas de crash (j'ai testé aussi: un kill de vi dans une autre fenêtre). et ce comportement me paraît très logique puisqu'on a forcément le droit d'écrire dans le répertoire du fichier que l'on édite.
C'est faux !
** root # mkdir -m751 /tmp/test_00 # cd /tmp/test_00 # touch a; chmod 666 a
** user % cd /tmp/test_00 % touch b touch: cannot touch `b': Permission denied % vi a % cat a coucou
Tu ne nous dis pas quels sont les droits réels de ton "user", selon son groupe il est dans le "5" ou dans le "1", pour que ça fonctionne je suppose qu'il est dans le "5", donc dans le groupe "root"
En tout cas chez moi je peux faire "cd /tmp/test_00 mais j'ai un "access deny" quand je fais simplement "ls", ce qui est normal.
Tu ne dis pas non plus ou se créé le fichier ".a.swp" quand tu modifies le fichier: probablement dans le ~/tmp du user, donc dans un répertoire qui survivra à un reboot, ce qui est le sujet de ce sous-fil.
Si les droits avaient été "777" (ou le user owner du répertoire) le swap aurait été créé directement dans /tmp/test_00 et là en effet les modifications en cours sont perdues en cas de crash.
Le 01/12/2011 23:53, Benoit Izac a écrit :
Bonjour,
le 01/12/2011 à 23:46, denis paris a écrit dans le message
<4ed803cc$0$25952$426a74cc@news.free.fr> :
OK, mais sur mon système (je viens de tester) vi créé un fichier
.monfichier.swp dans le même répertoire que le fichier en cours
d'édition, et propose de le récupérer en cas de crash (j'ai testé
aussi: un kill de vi dans une autre fenêtre). et ce comportement me
paraît très logique puisqu'on a forcément le droit d'écrire dans le
répertoire du fichier que l'on édite.
C'est faux !
** root
# mkdir -m751 /tmp/test_00
# cd /tmp/test_00
# touch a; chmod 666 a
** user
% cd /tmp/test_00
% touch b
touch: cannot touch `b': Permission denied
% vi a
% cat a
coucou
Tu ne nous dis pas quels sont les droits réels de ton "user", selon son
groupe il est dans le "5" ou dans le "1", pour que ça fonctionne je
suppose qu'il est dans le "5", donc dans le groupe "root"
En tout cas chez moi je peux faire "cd /tmp/test_00 mais j'ai un "access
deny" quand je fais simplement "ls", ce qui est normal.
Tu ne dis pas non plus ou se créé le fichier ".a.swp" quand tu modifies
le fichier: probablement dans le ~/tmp du user, donc dans un répertoire
qui survivra à un reboot, ce qui est le sujet de ce sous-fil.
Si les droits avaient été "777" (ou le user owner du répertoire) le swap
aurait été créé directement dans /tmp/test_00 et là en effet les
modifications en cours sont perdues en cas de crash.
le 01/12/2011 à 23:46, denis paris a écrit dans le message <4ed803cc$0$25952$ :
OK, mais sur mon système (je viens de tester) vi créé un fichier .monfichier.swp dans le même répertoire que le fichier en cours d'édition, et propose de le récupérer en cas de crash (j'ai testé aussi: un kill de vi dans une autre fenêtre). et ce comportement me paraît très logique puisqu'on a forcément le droit d'écrire dans le répertoire du fichier que l'on édite.
C'est faux !
** root # mkdir -m751 /tmp/test_00 # cd /tmp/test_00 # touch a; chmod 666 a
** user % cd /tmp/test_00 % touch b touch: cannot touch `b': Permission denied % vi a % cat a coucou
Tu ne nous dis pas quels sont les droits réels de ton "user", selon son groupe il est dans le "5" ou dans le "1", pour que ça fonctionne je suppose qu'il est dans le "5", donc dans le groupe "root"
En tout cas chez moi je peux faire "cd /tmp/test_00 mais j'ai un "access deny" quand je fais simplement "ls", ce qui est normal.
Tu ne dis pas non plus ou se créé le fichier ".a.swp" quand tu modifies le fichier: probablement dans le ~/tmp du user, donc dans un répertoire qui survivra à un reboot, ce qui est le sujet de ce sous-fil.
Si les droits avaient été "777" (ou le user owner du répertoire) le swap aurait été créé directement dans /tmp/test_00 et là en effet les modifications en cours sont perdues en cas de crash.
yamo'
Salut,
Nicolas George a tapoté, le 30/11/2011 18:46:
> http://doc.ubuntu-fr.org/ssd_solid_state_drive
Principe numéro 1 : les docs Ubuntu sont pourries. Principe numéro 2 : les docs en français sont pourries.
C'est dommage, personne pour corriger?
À noter qu'il existe un programme pour gérer la ram quand on en a beaucoup, comme je viens juste de passer de 1Go à 4 sur mon PC sur lubuntu 11.10, je l'ai testé et j'ai eu de gros problèmes avec ; j'ai du le désinstaller en mode recovery, pas pratique surtout qu'en mode recovery, je ne vois pas ce que je tape j'ai juste le résultat des commandes!
Peut-être que ça fonctionnera mieux chez d'autres.
J'ai fait un memtest (un seul test), sans trouver d'erreurs.
-- Stéphane
<http://pasdenom.info/fortune/>
Ce qui manque aux orateurs en profondeur, ils vous le donnent en longueur. -+- Montesquieu, Mes Pensées -+-
Salut,
Nicolas George a tapoté, le 30/11/2011 18:46:
> http://doc.ubuntu-fr.org/ssd_solid_state_drive
Principe numéro 1 : les docs Ubuntu sont pourries.
Principe numéro 2 : les docs en français sont pourries.
C'est dommage, personne pour corriger?
À noter qu'il existe un programme pour gérer la ram quand on en a
beaucoup, comme je viens juste de passer de 1Go à 4 sur mon PC sur
lubuntu 11.10, je l'ai testé et j'ai eu de gros problèmes avec ; j'ai du
le désinstaller en mode recovery, pas pratique surtout qu'en mode
recovery, je ne vois pas ce que je tape j'ai juste le résultat des
commandes!
Principe numéro 1 : les docs Ubuntu sont pourries. Principe numéro 2 : les docs en français sont pourries.
C'est dommage, personne pour corriger?
À noter qu'il existe un programme pour gérer la ram quand on en a beaucoup, comme je viens juste de passer de 1Go à 4 sur mon PC sur lubuntu 11.10, je l'ai testé et j'ai eu de gros problèmes avec ; j'ai du le désinstaller en mode recovery, pas pratique surtout qu'en mode recovery, je ne vois pas ce que je tape j'ai juste le résultat des commandes!
