[C] Routine om file aanwezigheid te testen

[Verwijderd]

Hallo,

Kan iemand mij aan een C-routine om de aanwezigheid van een file te testen, helpen?
De routine moet in ANSI-C zijn omdat hij gebruikt wordt in een pakket dat alleen ANSI-C scripting ondersteunt.

De test moet gedaan worden zonder dat de file, indien aanwezig, geopend wordt. Dus geen fopen; fclose statements, of pogingen de file te renamen.
Dit laatste is nodig omdat er vanaf een andere PC constant pogingen gedaan worden deze file te openen.

Bij voorbaat dank voor een ieders bijdrage

[XTerm]

code:

bool fileExist(char *filename)
{
  FILE *f
  f=fopen(filename,"r");
  if(f==NULL)
  {
    return(false);
  }
  else
  {
    fclose(f);
    return(true);
  }
}

[mbravenboer]

Vraag:

Dus geen fopen; fclose statements

Antwoord:

code:

f=fopen(filename,"r");

.

[XTerm]

Oops
* XTerm moet dringend leren lezen.
Maar wat is het probleem met fopen etc... die dingen zijn ANSI C, ik heb nog nooit een compiler/libraryset gezien die ze niet had...

[Bertrik]

Ik geloof dat de functie 'stat' of 'fstat' hiervoor bruikbaar is. Je kan ook een 'findfirst' doen op de volledige bestandsnaam.

[dusty]

Op zaterdag 26 januari 2002 08:47 schreef TRIS het volgende:
Hallo,
[..]
Bij voorbaat dank voor een ieders bijdrage

Graag niet groeten en/of bedanken aan het begin/eind. (zie faq)

[Soultaker]

Eigenlijk RTMF, maar hiervoor kun je stat gebruiken. fstat Is niet zo zinnig, aangezien je daarvoor de file eerst moet openen.

[Verwijderd]

zaterdag 26 januari schreef XTerm89D het volgende:

Maar wat is het probleem met fopen etc... die dingen zijn ANSI C, ik heb nog nooit een compiler/libraryset gezien die ze niet had...

Klopt het programma is een SCADA pakket en heeft deze functies ook. Dat is echter niet het probleem. Het probleem is dat het C-script om de 5 minuten een tekstbestand aanmaakt, dat een andere PC constant tracht te openen, verwerken en als laatste weer verwijdert.
Zonder voorziening treedt er in de tijd gezien een situatie op dat beide programma's gelijktijdig op dit bestand trachten toe te grijpen. Dit levert een conflict op. Dat laatste wil ik voorkomen door in het het C-script een test in te bouwen of het bestand al op de verwachte locatie aanwezig is.

Pogingen de aanwezigheid te testen midddels renamen of met fopen, triggeren dezelfde conflict situatie.

[.oisyn]

Op zaterdag 26 januari 2002 13:40 schreef Soultaker het volgende:
Eigenlijk RTMF, maar hiervoor kun je stat gebruiken. fstat Is niet zo zinnig, aangezien je daarvoor de file eerst moet openen.

Read zelf eens The Fucking Manual

De routine moet in ANSI-C zijn omdat hij gebruikt wordt in een pakket dat alleen ANSI-C scripting ondersteunt.

stat en fstat zijn niet ANSI-C

[.oisyn]

volgens mij is er geen andere optie dan met fopen kijken, die ook ANSI-C compatible is...

kun je geen gebruik maken van de API die het OS je biedt?

[XTerm]

Op zondag 27 januari 2002 18:26 schreef OiSyN het volgende:

[..]

Read zelf eens The Fucking Manual
[..]

stat en fstat zijn niet ANSI-C

Idd, want ik heb ook nog nooit gehoord van stat, en ik heb al ongeloofelijk veel functies in C/C++ uitgeprobeert

Btw ik ben verslaafd and man, maar ik lees soms wat snel

[igmar]

Kan iemand mij aan een C-routine om de aanwezigheid van een file te testen, helpen?
De routine moet in ANSI-C zijn omdat hij gebruikt wordt in een pakket dat alleen ANSI-C scripting ondersteunt.

De stat() functie.

[Verwijderd]

Nogmaals... de stat() functie is GEEN ANSI C

[Olaf van der Spek]

Op zondag 27 januari 2002 09:03 schreef TRIS het volgende:
zaterdag 26 januari schreef XTerm89D het volgende:

Maar wat is het probleem met fopen etc... die dingen zijn ANSI C, ik heb nog nooit een compiler/libraryset gezien die ze niet had...

Klopt het programma is een SCADA pakket en heeft deze functies ook. Dat is echter niet het probleem. Het probleem is dat het C-script om de 5 minuten een tekstbestand aanmaakt, dat een andere PC constant tracht te openen, verwerken en als laatste weer verwijdert.
Zonder voorziening treedt er in de tijd gezien een situatie op dat beide programma's gelijktijdig op dit bestand trachten toe te grijpen. Dit levert een conflict op. Dat laatste wil ik voorkomen door in het het C-script een test in te bouwen of het bestand al op de verwachte locatie aanwezig is.

Pogingen de aanwezigheid te testen midddels renamen of met fopen, triggeren dezelfde conflict situatie.

Wat wil je gaan doen nadat je hebt getest of het bestand aanwezig is dan?

[Sponz]

http://www.eskimo.com/~scs/C-faq/q19.11.html

[Verwijderd]

Op zondag 27 januari 2002 09:03 schreef TRIS het volgende:
zaterdag 26 januari schreef XTerm89D het volgende:

Maar wat is het probleem met fopen etc... die dingen zijn ANSI C, ik heb nog nooit een compiler/libraryset gezien die ze niet had...

Klopt het programma is een SCADA pakket en heeft deze functies ook. Dat is echter niet het probleem. Het probleem is dat het C-script om de 5 minuten een tekstbestand aanmaakt, dat een andere PC constant tracht te openen, verwerken en als laatste weer verwijdert.
Zonder voorziening treedt er in de tijd gezien een situatie op dat beide programma's gelijktijdig op dit bestand trachten toe te grijpen. Dit levert een conflict op. Dat laatste wil ik voorkomen door in het het C-script een test in te bouwen of het bestand al op de verwachte locatie aanwezig is.

Pogingen de aanwezigheid te testen midddels renamen of met fopen, triggeren dezelfde conflict situatie.

Kun je de pc die de file verwerkt niet eerst de file laten moven? Een move is een atomaire actie waardoor een lock conflict niet mogelijk is.

[drm]

euhhh, is dit niet typisch iets wat je met ASM op moet lossen

[.oisyn]

Op maandag 28 januari 2002 17:30 schreef drm het volgende:
euhhh, is dit niet typisch iets wat je met ASM op moet lossen

nee, dit is nou typisch iets wat je juist niet met asm op moet lossen

Als je dat doet zul je de hardware namelijk rechtstreeks aan moeten spreken. (Denk aan leeskoppen van de hdd op de juiste plek zetten, FAT inlezen, enz. Erg low-level allemaal, en totaal niet portable )

[Olaf van der Spek]

Op maandag 28 januari 2002 17:49 schreef OiSyN het volgende:

[..]

nee, dit is nou typisch iets wat je juist niet met asm op moet lossen

Als je dat doet zul je de hardware namelijk rechtstreeks aan moeten spreken. (Denk aan leeskoppen van de hdd op de juiste plek zetten, FAT inlezen, enz. Erg low-level allemaal, en totaal niet portable )

In ASM kun je toch ook gewoon fopen aanroepen?

[Sponz]

Op maandag 28 januari 2002 17:54 schreef OlafvdSpek het volgende:

[..]

In ASM kun je toch ook gewoon fopen aanroepen?

natuurlijk

tss..

[.oisyn]

Op maandag 28 januari 2002 17:54 schreef OlafvdSpek het volgende:

[..]

In ASM kun je toch ook gewoon fopen aanroepen?

uhm ja maar wat is dan het nut van het feit dat je asm gebruikt fopen aanroepen kan in C(++) ook

of, en dat dringt nu pas tot me door, drm bedoelt dat je dan interrupts kan gebruiken voor bepaalde OS functies... Maar ja, dat is ook OS afhankelijk (als het al zo werkt in bepaalde OS'en). Bovendien kom je dan op wat ik al eerder zei: gebruik maken van de API die het OS je biedt

[Verwijderd]

code om te kijken of een file bestaat, zowel voor Win32 als voor Unix platforms:
FXString en FXbool moet je maar zelf omzetten ...
(of gewoon FOX gebruiken)

code:

FXbool FXFile::exists(const FXString& file){
#ifndef WIN32
  struct stat status;
  return !file.empty() && (::stat(file.text(),&status)==0);
#else
  return !file.empty() && (GetFileAttributes(file.text())!=0xFFFFFFFF);
#endif
  }

oke... niet helemaal ansi-c, maar genoeg om je op weg te helpen...

[igmar]

Nogmaals... de stat() functie is GEEN ANSI C

Nee, maar wel de beste keus. Er is in ANSI C geen mogelijkheid om dit te testen zonder het risico te lopen dat het op bepaalde systemen niet werkt.

Het enige wat ANSI is is fopen(), en die wil de topicstarter niet gebruiken, wat betekend dat je zonder opties zit. stat() en acccess() zijn daarna de beste en veiligste keus zonder gezeik met locking issues.

[igmar]

Nee, maar wel de beste keus. Er is in ANSI C geen mogelijkheid om dit te testen zonder het risico te lopen dat het op bepaalde systemen niet werkt.

Het enige wat ANSI is is fopen(), en die wil de topicstarter niet gebruiken, wat betekend dat je zonder opties zit. stat() en acccess() zijn daarna de beste en veiligste keus zonder gezeik met locking issues.

Laatste opmerking : fopen(), stat() en access() zijn geen atomic operations. Je kan er dus NIET vanuit gaan dat als een van de drie goed gaat het openen/creeeren van de file altijd goed gaat. Gewoon netjes blijven checken op errors dus

[igmar]

Kun je de pc die de file verwerkt niet eerst de file laten moven? Een move is een atomaire actie waardoor een lock conflict niet mogelijk is.

De move is atomic, alleen alle open file descriptors naar dit bestand blijven gewoon bestaan. maw : het zal weinig oplossen. Ik vrees dat het echt OS specifieke oplossingen gaan worden

[.oisyn]

igmar, lees het begin van de thread nou even:

De routine moet in ANSI-C zijn omdat hij gebruikt wordt in een pakket dat alleen ANSI-C scripting ondersteunt.

ik heb even bepaalde belangrijke keywords dik gemaakt

[cobratbq]

Ik kan me nog vaag iets herinneren van een access functie.
access( ... ) Waarbij je de soort toegang op kunt vragen naar een bestand, alleen lezen, lezen/schrijven, of alleen testen of hij bestaat. En die is ook in gewoon Ansi-C toegankelijk, want ik heb hem zelf ook ooit onder C gebruikt.

[igmar]

Op dinsdag 29 januari 2002 00:07 schreef OiSyN het volgende:
igmar, lees het begin van de thread nou even:
[..]

ik heb even bepaalde belangrijke keywords dik gemaakt

Lees mij replies ook even en je zal zien dat er geen oplossing IS behalve fopen() die de poster NIET wil gebruiken.

[igmar]

m
Ik kan me nog vaag iets herinneren van een access functie.
access( ... ) Waarbij je de soort toegang op kunt vragen naar een bestand, alleen lezen, lezen/schrijven, of alleen testen of hij bestaat. En die is ook in gewoon Ansi-C toegankelijk, want ik heb hem zelf ook ooit onder C gebruikt.

Nope.. is een POSIX / BSD functie, niet ANSI.

[drm]

OiSyN:
uhm ja maar wat is dan het nut van het feit dat je asm gebruikt fopen aanroepen kan in C(++) ook

of, en dat dringt nu pas tot me door, drm bedoelt dat je dan interrupts kan gebruiken voor bepaalde OS functies... Maar ja, dat is ook OS afhankelijk (als het al zo werkt in bepaalde OS'en). Bovendien kom je dan op wat ik al eerder zei: gebruik maken van de API die het OS je biedt

Dat is idd wat ik bedoelde, jah... Maar nu ik er even over nadenk vind ik het ook nu ook niet zo'n goed idee meer als gister ...

Is er in ANSI-C geen manier om de directory uit te lezen?

[.oisyn]

Op dinsdag 29 januari 2002 09:09 schreef igmar het volgende:

[..]

Lees mij replies ook even en je zal zien dat er geen oplossing IS behalve fopen() die de poster NIET wil gebruiken.

ja maar dat zei ik al veel eerder, dus wat is je punt

.edit: en dan kun je wel aankomen met dat ie dan toch maar stat moet gebruiken, maar die functie is er gewoon niet in zijn library, dus hij KAN stat niet eens gebruiken

[Sponz]

Op dinsdag 29 januari 2002 09:09 schreef drm het volgende:

[..]

Is er in ANSI-C geen manier om de directory uit te lezen?

Nope. C is namelijk een portable taal, en er zijn platformen die geen directorys kennen. Zo zijn er ook platformen die geen files kennen, vandaar dat het testen op aanwezigheid van een file niet op portable manier te doen is.

[drm]

Sponz:
Nope. C is namelijk een portable taal, en er zijn platformen die geen directorys kennen. Zo zijn er ook platformen die geen files kennen, vandaar dat het testen op aanwezigheid van een file niet op portable manier te doen is.

Nou, TRIS, dan heb je dus pech

[Olaf van der Spek]

Ik snap eigenlijk nog niet wat er mis is met fopen op te testen op de aanwezigheid van een file. Op Linux locked fopen toch niet dus kan er toch ook niks mis gaan?

Dat je hier in principe niks aan hebt (fopen/move gaan nog steeds niet gegarandeerd goed) ok.