ifstream lecture de fichier disparu

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

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, 17h29

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é.

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

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...

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

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, 09h14

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, 11h13

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, 11h17

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, 11h30

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).

**koala01** · 23/10/2007, 13h33

Salut,

Ceci dit, le fait de vouloir supprimer un fichier dont tu sais qu'il est ouvert en input ne te paraît-il pas légèrement... suicidaire

**Mizar75** · 23/10/2007, 13h50

Envoyé par koala01

Salut,

Ceci dit, le fait de vouloir supprimer un fichier dont tu sais qu'il est ouvert en input ne te paraît-il pas légèrement... suicidaire

Pas seulement légérement ...... malheureusement je ne maitrise pas mes spec:

Un application ecrit, dans un fichier, des infos que je dois lire. Sur action de l'utilisateur (ou crash et redémarrage de l'appli) le fichier est detruit et re-créé (même nom mais pas même inode). A moi de detecter cette disparition pour le ré-ouvrir.

Je suis d'accord c'est NUL, pas performant, et tout et tout ... mais c'est mes spec.

Envoyé par hegros

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

C'est 3 sec

La taille est qq kilo au début pour flirter avec les Mo au bout de qq heures de fonctionnement.

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.

Nope ce qui m'interesse vraiment c'est le contenu.

**koala01** · 23/10/2007, 14h27

Envoyé par Mizar75

Pas seulement légérement ...... malheureusement je ne maitrise pas mes spec:

Un application ecrit, dans un fichier, des infos que je dois lire. Sur action de l'utilisateur (ou crash et redémarrage de l'appli) le fichier est detruit et re-créé (même nom mais pas même inode). A moi de detecter cette disparition pour le ré-ouvrir.

Je suis d'accord c'est NUL, pas performant, et tout et tout ... mais c'est mes spec.

Heu, tu parle bien d'une application tierce à ce que tu est occupé à mettre en oeuvre

(parce que, sinon, je ne vois pas l'intérêt: la fonction est quittée au moment où l'application crashe

)

Si oui, je verrais bien un truc du genre de

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
 void lafonction(const std::string& filename)
{
    //only application's death finishs this loop
    while(1) 
    {
        try
        {
             /* opens file or re-open it after crash */
             std::ifstream input(filename.c_str());
             std::string line;
             while(getline(input, line))
             {
                  cout << "Ligne lue [" << ligne << "]." << endl;
                  /* hoping sync works */
                  input.sync();
             }
        }
        catch(std::exception &e)
        {
            std::cout<<"some reading problem occures... exception catched :"
                 <<e.what()<<endl
                 <<"external application seems to have crashed... "
                 <<"waiting some time to allow app to restart"<<std::endl;
            /* waiting for some times, to be sure that file exists again */
            sleep(5); /*be carefull: sleep time changes between win and lin */
        }
    }
}

**Mizar75** · 23/10/2007, 14h56

Envoyé par koala01

Heu, tu parle bien d'une application tierce à ce que tu est occupé à mettre en oeuvre

(parce que, sinon, je ne vois pas l'intérêt: la fonction est quittée au moment où l'application crashe

)

Oui

Envoyé par koala01

Si oui, je verrais bien un truc du genre de

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
 void lafonction(const std::string& filename)
{
    //only application's death finishs this loop
    while(1) 
    {
 
        try
        {
             /* opens file or re-open it after crash */
             std::ifstream input(filename.c_str());
             std::string line
             while(getline(input, line)
             {
                  cout << "Ligne lue [" << ligne << "]." << endl;
                  /* hoping sync works */
                  input.sync();
             }
        }
        catch(std::exception &e)
        {
            std::cout<<"some reading problem occures... exception catched :"
                 <<e.what()<<endl
                 <<"external application seems to have crashed... "
                 <<"waiting some time to allow app to restart"<<std::endl;
            /* waiting for some times, to be sure that file exists again */
            sleep(5) /*be carefull: sleep time changes between win and lin */
        }
    }
}

Ca à l'air bien. Je vais tenter.

Merci

**koala01** · 23/10/2007, 15h01

Autant préciser que ce code est donné "en vrac", sans même la moindre tentative de compilation...

La logique me semble être bonne, mais je ne jurerais pas qu'il n'y a pas d'erreur de syntaxe, ni que le codage fasse réellement ce que j'avais en tête

Un simple exemple: la relecture m'a fait "tomber" sur un ; manquant apres le sleep dans le catch

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

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, 16h02

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

**Mizar75** · 23/10/2007, 16h03

Je vais m'ammuser.
Merci à tous pour vos réponses.

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

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, 16h11

Autant poser un verrou et basta, paf !

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

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.