La fread est-elle possible après la suppression d'un fichier?

Question

J'ai ouvert un flux de fichier vers un très gros fichier en utilisant fopen. Avant d'effectuer une opération de lecture sur ce flux, j'ai supprimé le fichier en utilisant unlink(). Et encore, j'ai été capable de lire tout le fichier.

Je suppose qu'il existe un tampon associé au flux, qui contient les données du fichier. Mais évidemment, ce tampon aura une limite. C'est la raison pour laquelle j'ai choisi a_big_file dont la taille était 551126688 octets ou 526MB.

Je veux savoir quelle est la raison exacte derrière cela. Voici le code de test que j'ai utilisé.

#include <stdio.h> 
#include <unistd.h> 

int main(){ 

    FILE *fp; 
    long long int file_size = 0; 
    int bytes_read = 0; 
    char buf[1]; 

    fp = fopen("a_big_file", "r"); 

    unlink("a_big_file"); 

    while(0 != (bytes_read = fread(buf, 1, 1, fp))){ 
     file_size += bytes_read; 
    } 

    printf("file_size is %llu\n", file_size); 

    return 0; 
} 

Sortie: file_size est 551126688

Answer 1

Dans les systèmes d'exploitation Unix et Unix, le fichier ne disparaît pas vraiment jusqu'à ce que le dernier fichier ouvert sur elle est fermée. C'est une astuce très utile pour les fichiers temporaires - si vous le déconnectez dès que vous l'ouvrez, le fichier ne sera pas visible pour les autres processus, et il sera supprimé du système dès que votre programme le ferme, se termine ou des accidents. Cela permet d'éviter la prolifération des fichiers temporaires orphelins. Pratiquement (en passant en revue quelques détails techniques ici), les systèmes de fichiers Unix sont comptés. Lorsque vous ouvrez le fichier, vous êtes réellement connecté à l'inode du fichier (qui est l'indication réelle de l'endroit où le contenu réel du fichier vit). Mais dissocier le fichier supprime simplement l'entrée du répertoire, de sorte que le fichier n'a plus de nom. Le système de fichiers récupérera seulement l'espace de fichier (c.-à-d. L'inode) s'il n'est dans aucune entrée de répertoire, ET que personne ne l'a ouvert. Les autres processus ne peuvent pas l'ouvrir de la manière habituelle car ils ne peuvent pas associer un nom de fichier à l'i-noeud.

Notez que les systèmes de fichiers Unix permettent à plusieurs entrées d'annuaire de pointer vers le même inode - nous appelons cela un "lien dur". Si vous faites un "ls -l", l'un des champs est le nombre de liens durs vers ce même inode, et si vous faites un "ls -li", vous pouvez voir l'adresse inode réelle.

Answer 2

De la page de manuel pour unlink:

unlink() supprime un nom du système de fichiers . Si ce nom était le dernier lien vers un fichier et aucun processus ont le fichier ouvrir le fichier est supprimé et l'espace utilisé était disponible pour une réutilisation.

Si le nom était le dernier lien vers un fichier, mais tous les processus ont encore le fichier ouvrir le fichier restera en existence jusqu'à ce que le dernier fichier descripteur se référant à elle est fermée.

Le bit en gras explique le comportement. :-)

[modifier] BTW vous devriez vraiment fermer le fichier avec fclose() avant la déclaration de retour ... [/ modifier]

Answer 3

Dans Linux, le fichier est vraiment retiré que lorsque sa dernière poignée ouverte est fermé.

Les gens utilisent généralement des fichiers temporaires de cette façon: mkstemp(3) suivi immédiatement de unlink(2). De cette façon, vous seul pouvez accéder aux données du fichier, aucun autre processus ne peut.

Même si un autre processus crée un autre fichier portant le même nom, le nouveau fichier n'aura rien en commun avec le fichier d'origine.

Answer 4

Sur certains systèmes, tels que Linux, vous pouvez facilement accéder aux fichiers qui n'ont pas de nom sur le système de fichiers tant qu'un processus l'a toujours ouvert. Il y a une liste de descripteurs de fichiers dans

/proc/<pid>/fd 

Modifier: Selon le commentaire de Paul Tomblin, vous ne pouvez accéder à ce répertoire si vous êtes le même utilisateur que le processus ou la racine.

Par exemple:

# Create a file with cat 
chris@shrubbery:~$ cat > MYFILE 
Hello 

# Suspend the process and find its pid 
[1]+ Stopped     cat > MYFILE 
chris@shrubbery:~$ ps waux | grep cat 
chris  1311 0.0 0.0 5088 668 pts/6 T 14:29 0:00 cat 
chris  1313 0.0 0.0 5168 840 pts/6 R+ 14:29 0:00 grep cat 

# Inspect the list of open files 
chris@shrubbery:~$ cd /proc/1311/fd 
chris@shrubbery:/proc/1311/fd$ ls -l 
total 0 
lrwx------ 1 chris chris 64 2009-02-03 14:29 0 -> /dev/pts/6 
l-wx------ 1 chris chris 64 2009-02-03 14:29 1 -> /home/chris/MYFILE 
lrwx------ 1 chris chris 64 2009-02-03 14:29 2 -> /dev/pts/6 

# View MYFILE from the symlink on the /proc pseudofilesystem. 
chris@shrubbery:/proc/1311/fd$ cat 1 
Hello 

# Delete the filename /home/chris/MYFILE 
chris@shrubbery:/proc/1311/fd$ rm /home/chris/MYFILE 
chris@shrubbery:/proc/1311/fd$ cat /home/chris/MYFILE 
cat: /home/chris/MYFILE: No such file or directory 

# But the process still has it open. 
# The /proc system knows the original name was deleted 
chris@shrubbery:/proc/1311/fd$ ls -l 
total 0 
lrwx------ 1 chris chris 64 2009-02-03 14:29 0 -> /dev/pts/6 
l-wx------ 1 chris chris 64 2009-02-03 14:29 1 -> /home/chris/MYFILE (deleted) 
lrwx------ 1 chris chris 64 2009-02-03 14:29 2 -> /dev/pts/6 

# We can still view the file, useful for debugging. 
chris@shrubbery:/proc/1311/fd$ cat 1 
Hello