mv un fichier dans / dev / null interrompt dev / null

Si je le fais: en touch file; mv file /dev/nulltant que root, /dev/nulldisparaît. ls -lad /dev/nullrésulte en aucun fichier ou répertoire. Cela casse les applications qui dépendent de /dev/nullSSH similaires et peuvent être résolues en faisant mknod /dev/null c 1 3; chmod 666 /dev/null. Pourquoi le déplacement d'un fichier normal vers ce fichier spécial entraîne-t-il la disparition de /dev/null?

Pour clarifier, c'était à des fins de test, et je comprends comment fonctionne la mvcommande. Ce que je suis curieux de savoir, c'est pourquoi ls -la /dev/nullavant de le remplacer par un fichier normal, la sortie attendue est affichée, mais ensuite cela montre que cela /dev/nulln'existe pas même si un fichier aurait été créé via la mvcommande d' origine et que la commande de fichier affiche du texte ASCII. Je pense que cela doit être une combinaison du lscomportement de la commande en conjonction avec devfsquand un fichier non spécial remplace un fichier caractère / spécial. C'est sur Mac OS X, les comportements peuvent varier sur d'autres OS.

En regardant le code source de mv, http://www.opensource.apple.com/source/file_cmds/file_cmds-220.7/mv/mv.c :

/*
 * If rename fails because we're trying to cross devices, and
 * it's a regular file, do the copy internally; otherwise, use
 * cp and rm.
 */
if (lstat(from, &sb)) {
    warn("%s", from);
    return (1);
}
return (S_ISREG(sb.st_mode) ?
    fastcopy(from, to, &sb) : copy(from, to));

...

int
fastcopy(char *from, char *to, struct stat *sbp)
{
...
while ((to_fd =
    open(to, O_CREAT | O_EXCL | O_TRUNC | O_WRONLY, 0)) < 0) {
        if (errno == EEXIST && unlink(to) == 0)
            continue;
        warn("%s", to);
        (void)close(from_fd);
        return (1);
}

Lors du premier passage dans la boucle while, open(to, O_CREAT | O_EXCL | O_TRUNC | O_WRONLY, 0)échouera avec EEXIST. Puis /dev/nullsera dissocié et la boucle répétée. Mais comme vous l'avez souligné dans votre commentaire, les fichiers normaux ne peuvent pas être créés /dev, donc lors du prochain passage dans la boucle, cela open(to, O_CREAT | O_EXCL | O_TRUNC | O_WRONLY, 0)échouera toujours.

Je déposerais un rapport de bogue avec Apple. Le mvcode source est pratiquement inchangé par rapport à la version FreeBSD, mais comme le devfs d'OSX a ce comportement non-POSIX avec les fichiers normaux, Apple devrait corriger leur mv.

Le déplacement d'un fichier vers l'emplacement d'un fichier déjà existant remplace le fichier existant. Dans ce cas, le /dev/nullfichier de périphérique est remplacé, tout comme n'importe quel fichier normal. Pour éviter cela, utilisez l' option -i(interactive, avertit avant d'écraser) ou -n(pas de clober) pour mv.

/dev/nullne remplit sa fonction spéciale que comme un ensemble de bits, puis l'appareil est ouvert tel quel. Par exemple, lorsque l' >opérateur shell est utilisé, le fichier est ouvert puis tronqué (non supprimé et remplacé, ce qui peut être ce que vous attendiez). Comme mentionné par casey, la bonne façon de supprimer un fichier est avec rmou même avec unlink.

Umm, parce que vous écrasez le fichier spécial avec un fichier normal? À quoi vous attendiez-vous? dev/nulln'est pas un répertoire, c'est un fichier pointant vers un nullpériphérique. Lorsque vous avez mvquelque chose, vous supprimez l'original et le remplacez par ce que vous avez déplacé:

$ file /dev/null 
/dev/null: character special 
$ sudo mv file /dev/null 
$ file /dev/null 
/dev/null: ASCII text