Si nous utilisons echo 1234 >> some-file
alors Documentation dit que la sortie est ajoutée.
Je suppose que si un fichier n'existe pas, alors O_CREAT créera un nouveau fichier. Si a >
été utilisé, alors O_TRUNC tronquera le fichier existant.
Dans le cas de >>
: Le fichier sera-t-il ouvert en tant que O_WRONLY (ou O_RDWR) et la fin de l'opération recherchée, l'opération d'écriture est effectuée, en simulant O_APPEND? Ou le fichier sera-t-il ouvert en tant que O_APPEND, laissant au noyau le soin de s'assurer que l'ajout se produit?
Je vous pose cette question car un processus de conservation remplace certains marqueurs insérés par echo, lorsque le fichier de sortie provient du point de montage NFS. La documentation NFS indique que O_APPEND n'est pas pris en charge sur le serveur. Le noyau du client devra donc le gérer. Je suppose que le processus de conservation utilise O_APPEND, mais n'est pas sûr de bash >>
sur linux, posant donc la question ici.
O_APPEND
n’est pas supporté; le problème est qu'il est imité. Sur un système de fichiers local, plusieurs processus écrivant dans le même fichier ouvert avecO_APPEND
ne seront jamais écraser les données de chacun; sur NFS,O_APPEND
est imité en cherchant jusqu'au bout avant d'écrire, ce qui laisse la possibilité de conditions de concurrence. Il n'y a aucun moyen de contourner cela sur NFS; chaque rédacteur parallèle doit écrire son propre fichier. La seule façon de contourner ce problème consiste à configurer un processus serveur sur le serveur NFS, à enregistrer les enregistreurs|nc server port
et à faire en sorte que le serveur ajoute les données entrantes au journal.