ifstream lecture de fichier disparu

**Mizar75** · 22/10/2007, 18h15

Hello

Quelqu'un peux t'il m'expliquer comment cela se fait:
Je suis sur linux et j'ai un programme qui lis un fichier à l'aide d'un ifstream.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
ifstream input("fichier.txt");
string ligne;
while (1)
{
  while(getline(input, ligne))
  {
    cout << "Ligne lue [" << ligne << "]." << endl;
    sleep(3);
    input.sync();
  }
}

Je ralentis la lecture avec le sleep pour avoir le temp de faire un RM de fichier.txt alors qu'il reste encore des lignes à lire.
Et bin ce prog continue à lire ces lignes (pourtant je synchronise à chaque coup).
Comment y fait? le sync() ne remais pas à jour le buffer?
Comment puis-je détecter la disparition du fichier? (parce que c'est surtout ca qui m'interesse)

**hegros** · 22/10/2007, 18h29

Mauvais forum ici c'est C.

Sinon getline ne génére pas une exception ou ne renvoi pas de code erreur ?

Pour sync il faut lire la documentation c'est normalement expliqué.

**Mizar75** · 23/10/2007, 10h07

Envoyé par hegros

Sinon getline ne génére pas une exception ou ne renvoi pas de code erreur ?

Et non il continue comme si de rien n'était

Envoyé par hegros

Pour sync il faut lire la documentation c'est normalement expliqué.

Trop facile.
Le man est léger et semble allez dans mon sens: "Synchronize input buffer with source of characters" [synchronise le buffer d'entrée avec la source de charactères]
Pourtant cela ne marche pas

Envoyé par Médinoc

Normalement, un fichier ouvert en lecture est verrouillé automatiquement pour ne pas être modifié ni supprimé.

Sous windows oui mais pas sous linux

Envoyé par Médinoc

Sous un système unixoïde, je suppose que le fichier est immédiatement retiré du répertoire, mais qu'il ne disparait vraiment qu'après la fermeture de tous les descripteurs pointant dessus...

Possible ou alors c'est le cache de lecture du disque dur qui conserve la mémoire du fichier. Quoi qu'il en soit c'est concervé

**JolyLoic** · 23/10/2007, 10h14

Si tu veux juste tester si ton fichier existe, je te conseillerai d'utiliser les fonctions spécifiques à ton OS qui indiquent si un fichier existe.

**hegros** · 23/10/2007, 12h13

Envoyé par JolyLoic

Si tu veux juste tester si ton fichier existe, je te conseillerai d'utiliser les fonctions spécifiques à ton OS qui indiquent si un fichier existe.

Oui mais dans ce cas tu fais comment, tu testes son existence à chaque tour de boucle ?

Envoyé par Mizar75

Trop facile.

Si la doc n'en dit pas plus...

**hegros** · 23/10/2007, 12h17

Essaie d'allonger le temps de ton sleep, 3millisecondes et peut être trop court pour sync. Quelle taille fait le fichier ?

**JolyLoic** · 23/10/2007, 12h30

Envoyé par hegros

Oui mais dans ce cas tu fais comment, tu testes son existence à chaque tour de boucle ?

Soit ça, soit tu utilises des fonctions de l'OS qui te notifient lors d'une modification d'un répertoire (je ne sais pas s'il en existe sous Linux).

**Médinoc** · 22/10/2007, 18h31

Normalement, un fichier ouvert en lecture est verrouillé automatiquement pour ne pas être modifié ni supprimé.

Sous un système unixoïde, je suppose que le fichier est immédiatement retiré du répertoire, mais qu'il ne disparait vraiment qu'après la fermeture de tous les descripteurs pointant dessus...

**Jean-Marc.Bourguet** · 23/10/2007, 16h39

La supposition de Médinoc est correcte: l'effacement ne fait qu'enlever la reference a un fichier dans le repertoire. Le fichier n'est reellement detruit que quand il n'existe plus aucunes references (entrees dans les repertoires -- avec les liens hard, on peut en avoir plusieurs pour le meme fichier -- et ouvertures). Une technique habituelle sous Unix pour les fichiers temporaires est de les ouvrir puis de les effacer. Ils continuent a exister jusqu'a ce qu'on les ferme.

Donc le seul moyen de savoir que le fichier a changer, est de noter son inode au depart (et son device tant qu'a faire pour eviter les petits jeux avec les liens symboliques) et de verifier periodiquement (a chaque lecture, toutes les n lectures...) que c'est bien toujours le meme fichier (meme device, meme inode). Et encore, j'ai un doute que ca marche avec les systemes de fichiers distribues (genre NFS).

**hegros** · 23/10/2007, 17h02

Une autre solution serait aussi de poser un verrou exclusif sur le fichier. Ainsi la tentative d'effacement sera rejeté par le système, si ca rentre dans tes specs biensûr

**pyrho** · 23/10/2007, 17h07

Une methode sale: Tu peux essayer d'ouvrir le fichier sur un autre ifstream et verifier la reussite de cette operation.

J'ai honte, c'est vraiment moche

mais ca marche.

**hegros** · 23/10/2007, 17h11

Autant poser un verrou et basta, paf !

**Mizar75** · 24/10/2007, 12h53

Envoyé par hegros

Autant poser un verrou et basta, paf !

Malheureusement ceci empechera l'autre application d'alimenter le fichier en données.

**Mizar75** · 24/10/2007, 12h52

Envoyé par pyrho

Une methode sale: Tu peux essayer d'ouvrir le fichier sur un autre ifstream et verifier la reussite de cette operation.

J'ai honte, c'est vraiment moche

mais ca marche.

c'est une bidouille mais elle marche dans y'a pas de honte a avoir.