Sous GNU/Linux, je viens d'observer un comportement qui m'a surpris.
Je voulais mettre à jour un exécutable, dont il se trouve qu'une
instance était en cours d'exécution, et cp n'a pas voulu :
mpg@roth:~/src/luatex% cp build/texk/web2c/luatex
~/tl/trunk/Master/bin/local-build-luatex
cp: ne peut créer le fichier régulier
`/home/mpg/tl/trunk/Master/bin/local-build-luatex/luatex': Fichier texte occupé
Pourtant il me semblait qu'avec les systèmes de fichiers traditionnels
des Unixoïdes (ici, c'est une partition ext3), il était parfaitement
possible de modifier un fichier en cours d'utilisation. Est-ce que le
comportement observé provient juste du fait que GNU cp ne s'y prend pas
comme il faut pour ça ? Si oui, avez-vous une idée de pourquoi (sans
trop troller contre GNU) ? Sinon, qu'est-ce qui m'a échappé ?
Merci d'avance.
--
Manuel Pégourié-Gonnard Institut de mathématiques de Jussieu
http://weblog.elzevir.fr/ http://people.math.jussieu.fr/~mpg/
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Emmanuel Florac
Le Mon, 29 Mar 2010 14:49:32 +0200, Manuel Pégourié-Gonnard a écrit:
Si oui, avez-vous une idée de pourquoi (sans trop troller contre GNU) ? Sinon, qu'est-ce qui m'a échappé ?
Le fichier était sans doute verrouillé, et cp tient compte des verrous ce qui est une très bonne chose. Le FS lui-même de fait n'aurait pas empéché l'effacement/écrasement d'un fichier verrouillé.
-- That ideas should freely spread from one to another over the globe, for the moral and mutual instruction of man, and the improvement of his conditions, seems to have been peculiarly and benevolently designed by nature, when she made them, like fire, expansible over all space, without lessening their density in any point, and like the air in which we breathe, move, and have our physical being, incapable of confinement of exclusive appropriation. Inventions then cannot, in nature, be a subject of property. Thomas Jefferson.
Le Mon, 29 Mar 2010 14:49:32 +0200, Manuel Pégourié-Gonnard a écrit:
Si oui, avez-vous une idée de pourquoi (sans
trop troller contre GNU) ? Sinon, qu'est-ce qui m'a échappé ?
Le fichier était sans doute verrouillé, et cp tient compte des verrous ce
qui est une très bonne chose. Le FS lui-même de fait n'aurait pas empéché
l'effacement/écrasement d'un fichier verrouillé.
--
That ideas should freely spread from one to another over the globe,
for the moral and mutual instruction of man, and the improvement of his
conditions, seems to have been peculiarly and benevolently designed by
nature, when she made them, like fire, expansible over all space,
without lessening their density in any point, and like the air in which
we breathe, move, and have our physical being, incapable of confinement
of exclusive appropriation. Inventions then cannot, in nature, be a
subject of property.
Thomas Jefferson.
Le Mon, 29 Mar 2010 14:49:32 +0200, Manuel Pégourié-Gonnard a écrit:
Si oui, avez-vous une idée de pourquoi (sans trop troller contre GNU) ? Sinon, qu'est-ce qui m'a échappé ?
Le fichier était sans doute verrouillé, et cp tient compte des verrous ce qui est une très bonne chose. Le FS lui-même de fait n'aurait pas empéché l'effacement/écrasement d'un fichier verrouillé.
-- That ideas should freely spread from one to another over the globe, for the moral and mutual instruction of man, and the improvement of his conditions, seems to have been peculiarly and benevolently designed by nature, when she made them, like fire, expansible over all space, without lessening their density in any point, and like the air in which we breathe, move, and have our physical being, incapable of confinement of exclusive appropriation. Inventions then cannot, in nature, be a subject of property. Thomas Jefferson.
Stephane CHAZELAS
2010-03-29, 14:49(+02), Manuel Pégourié-Gonnard: [...]
Sous GNU/Linux, je viens d'observer un comportement qui m'a surpris. Je voulais mettre à jour un exécutable, dont il se trouve qu'une instance était en cours d'exécution, et cp n'a pas voulu :
:~/src/luatex% cp build/texk/web2c/luatex ~/tl/trunk/Master/bin/local-build-luatex cp: ne peut créer le fichier régulier `/home/mpg/tl/trunk/Master/bin/local-build-luatex/luatex': Fichier texte occupé
Pourtant il me semblait qu'avec les systèmes de fichiers traditionnels des Unixoïdes (ici, c'est une partition ext3), il était parfaitement possible de modifier un fichier en cours d'utilisation. Est-ce que le comportement observé provient juste du fait que GNU cp ne s'y prend pas comme il faut pour ça ? Si oui, avez-vous une idée de pourquoi (sans trop troller contre GNU) ? Sinon, qu'est-ce qui m'a échappé ?
[...]
A l'execution, l'editeur de lien dynamique ou le kernel a mmap(2)pé le fichier en question avec MAP_DENYWRITE (ce qu'il fait pour tout fichié executé), ce qui fait que tout open(2) en WR_ONLY on RDWR retourne avec l'erreur ETXTBSY. Ce n'est pas au niveau du systeme de fichier. Linux aussi empeche l'execution si le fichier executable est ouvert par un autre process en ecriture. Ce n'est pas specifique a Linux (MAP_DENYWRITE l'est probablement toutefois). "POSIX [...] neither requires nor prohibits that behavior".
cp(1) ouvre le fichier de destination en ecriture, si tu veux qu'il cree un nouveau fichier en cas d'echec du open(2), il faut lui passer l'option -f.
install(1) efface toujours le fichier de destination s'il existe avant de creer le nouveau (a moins de passer des options de backup).
-- Stéphane
2010-03-29, 14:49(+02), Manuel Pégourié-Gonnard:
[...]
Sous GNU/Linux, je viens d'observer un comportement qui m'a surpris.
Je voulais mettre à jour un exécutable, dont il se trouve qu'une
instance était en cours d'exécution, et cp n'a pas voulu :
mpg@roth:~/src/luatex% cp build/texk/web2c/luatex
~/tl/trunk/Master/bin/local-build-luatex
cp: ne peut créer le fichier régulier
`/home/mpg/tl/trunk/Master/bin/local-build-luatex/luatex': Fichier texte occupé
Pourtant il me semblait qu'avec les systèmes de fichiers traditionnels
des Unixoïdes (ici, c'est une partition ext3), il était parfaitement
possible de modifier un fichier en cours d'utilisation. Est-ce que le
comportement observé provient juste du fait que GNU cp ne s'y prend pas
comme il faut pour ça ? Si oui, avez-vous une idée de pourquoi (sans
trop troller contre GNU) ? Sinon, qu'est-ce qui m'a échappé ?
[...]
A l'execution, l'editeur de lien dynamique ou le kernel a
mmap(2)pé le fichier en question avec MAP_DENYWRITE (ce qu'il
fait pour tout fichié executé), ce qui fait que tout open(2) en
WR_ONLY on RDWR retourne avec l'erreur ETXTBSY. Ce n'est pas au
niveau du systeme de fichier. Linux aussi empeche l'execution si
le fichier executable est ouvert par un autre process en
ecriture. Ce n'est pas specifique a Linux (MAP_DENYWRITE l'est
probablement toutefois). "POSIX [...] neither requires nor
prohibits that behavior".
cp(1) ouvre le fichier de destination en ecriture, si tu veux qu'il
cree un nouveau fichier en cas d'echec du open(2), il faut lui
passer l'option -f.
install(1) efface toujours le fichier de destination s'il existe
avant de creer le nouveau (a moins de passer des options de
backup).
2010-03-29, 14:49(+02), Manuel Pégourié-Gonnard: [...]
Sous GNU/Linux, je viens d'observer un comportement qui m'a surpris. Je voulais mettre à jour un exécutable, dont il se trouve qu'une instance était en cours d'exécution, et cp n'a pas voulu :
:~/src/luatex% cp build/texk/web2c/luatex ~/tl/trunk/Master/bin/local-build-luatex cp: ne peut créer le fichier régulier `/home/mpg/tl/trunk/Master/bin/local-build-luatex/luatex': Fichier texte occupé
Pourtant il me semblait qu'avec les systèmes de fichiers traditionnels des Unixoïdes (ici, c'est une partition ext3), il était parfaitement possible de modifier un fichier en cours d'utilisation. Est-ce que le comportement observé provient juste du fait que GNU cp ne s'y prend pas comme il faut pour ça ? Si oui, avez-vous une idée de pourquoi (sans trop troller contre GNU) ? Sinon, qu'est-ce qui m'a échappé ?
[...]
A l'execution, l'editeur de lien dynamique ou le kernel a mmap(2)pé le fichier en question avec MAP_DENYWRITE (ce qu'il fait pour tout fichié executé), ce qui fait que tout open(2) en WR_ONLY on RDWR retourne avec l'erreur ETXTBSY. Ce n'est pas au niveau du systeme de fichier. Linux aussi empeche l'execution si le fichier executable est ouvert par un autre process en ecriture. Ce n'est pas specifique a Linux (MAP_DENYWRITE l'est probablement toutefois). "POSIX [...] neither requires nor prohibits that behavior".
cp(1) ouvre le fichier de destination en ecriture, si tu veux qu'il cree un nouveau fichier en cas d'echec du open(2), il faut lui passer l'option -f.
install(1) efface toujours le fichier de destination s'il existe avant de creer le nouveau (a moins de passer des options de backup).
-- Stéphane
Paul Gaborit
À (at) 29 Mar 2010 13:48:11 GMT, Emmanuel Florac écrivait (wrote):
Le Mon, 29 Mar 2010 14:49:32 +0200, Manuel Pégourié-Gonnard a écrit:
Si oui, avez-vous une idée de pourquoi (sans trop troller contre GNU) ? Sinon, qu'est-ce qui m'a échappé ?
Le fichier était sans doute verrouillé, et cp tient compte des verrous ce qui est une très bonne chose. Le FS lui-même de fait n'aurait pas empéché l'effacement/écrasement d'un fichier verrouillé.
Je ne pense pas que 'cp' tienne compte des éventuels verrous. Par contre, si le fichier existe déja, il essaye d'en remplacer le contenu sans effacer le fichier lui-même. Et il ne peut pas le faire si on n'a pas le droit de modifier ce fichier pré-existant. D'où les option '-f' ou '-n'...
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) 29 Mar 2010 13:48:11 GMT,
Emmanuel Florac <eflorac@imaginet.fr> écrivait (wrote):
Le Mon, 29 Mar 2010 14:49:32 +0200, Manuel Pégourié-Gonnard a écrit:
Si oui, avez-vous une idée de pourquoi (sans
trop troller contre GNU) ? Sinon, qu'est-ce qui m'a échappé ?
Le fichier était sans doute verrouillé, et cp tient compte des verrous ce
qui est une très bonne chose. Le FS lui-même de fait n'aurait pas empéché
l'effacement/écrasement d'un fichier verrouillé.
Je ne pense pas que 'cp' tienne compte des éventuels verrous. Par
contre, si le fichier existe déja, il essaye d'en remplacer le contenu
sans effacer le fichier lui-même. Et il ne peut pas le faire si on n'a
pas le droit de modifier ce fichier pré-existant. D'où les option '-f'
ou '-n'...
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) 29 Mar 2010 13:48:11 GMT, Emmanuel Florac écrivait (wrote):
Le Mon, 29 Mar 2010 14:49:32 +0200, Manuel Pégourié-Gonnard a écrit:
Si oui, avez-vous une idée de pourquoi (sans trop troller contre GNU) ? Sinon, qu'est-ce qui m'a échappé ?
Le fichier était sans doute verrouillé, et cp tient compte des verrous ce qui est une très bonne chose. Le FS lui-même de fait n'aurait pas empéché l'effacement/écrasement d'un fichier verrouillé.
Je ne pense pas que 'cp' tienne compte des éventuels verrous. Par contre, si le fichier existe déja, il essaye d'en remplacer le contenu sans effacer le fichier lui-même. Et il ne peut pas le faire si on n'a pas le droit de modifier ce fichier pré-existant. D'où les option '-f' ou '-n'...
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
