I want to see if a file exists. in C

wilsonsamm

Is this what they call a lockfile?

I'm trying to write some software that translates from one language to another (as some of you probably know, I learn a few languages and grew up bilingually with Norwegian and English)

Process A does some calculations, and puts the result into file A. (It takes a text file and spits it out, sentence by sentence, stripping out whitespace, converting from foreign charsets etc...)

Then process B does computations on the sentence in file A, and writes the results to file B (sentence by sentence it tries to interpret the language, finding the verb, looking up words in a wordlist, stuff like that) and writes the results of his calculations to file B for the next process to pick up, etc etc etc.

If I have Process B delete file A when it's done, and process A check for the existence of file A (to see if proc B is ready to receive another batch) then can I expect that piece by piece, information will be sent to the next process?

Am I making sense?

Anyway, how can I check in C if a file exists or not?

Winston

My answer would be: don't use an intermediate file at all, use a pipe*. Process A and B shouldn't have to care whether one's ready or not - process A should just write whenever it's ready, and process B empty the pipe when it can.

Additionally, I'd suggest C isn't the right language for analyzing the incoming text, there are better languages for that. Don't be dogmatic about the language you use - just use the right tool for the job.

(either stdout for process A, and stdin for process B - or a named pipe or FIFO if the application really demands it)

bobs

wilsonsamm wrote: »

Anyway, how can I check in C if a file exists or not?

I think _access(<filename>, <flags>) exists in C. If flags is 0 then existence is checked.

Winston

From the BSD manpage for access(2):

CAVEAT
Access() is a potential security hole and should never be used.

...although it's only a potential security hole in certain circumstances, probably not in the way you want to use it. (Note that if you check a file with access(), and then later open it, you have a race condition with other processes - some other process can change the file between access() and open(), and the file you open may not be the same one you called access upon. Generally, it's better to open the file then use the file descriptor to look at the file's attributes, because you're guaranteed to be looking at the same object.)

But really, use a pipe for what you want to do. Unless there's a reason you've not revealed which makes an intermediate file absolutely mandatory, this is the very thing pipes were designed for, and it'll make your programs more flexible.

wilsonsamm

What language, or what kind of language, do you then suggest I use? I chose C because I already know it a little, and I had a bias against using BASIC because GCC doesn't have a compiler for it.

EDIT: I don't mind learning a computer language at all, for this purpose.

JamesW

wilsonsamm wrote: »

What language, or what kind of language, do you then suggest I use? I chose C because I already know it a little, and I had a bias against using BASIC because GCC doesn't have a compiler for it.

EDIT: I don't mind learning a computer language at all, for this purpose.

You're doing string wrangling aren't you? Perl or Python would likely be a good match.

Jmk

Why not just try opening the file for reading? If it works then it exists. Or use findfirst() in an unusual manner, by specifying an exact file rather than a wildcard.

For a lockfile, I guess you would just create a second file (zero-bytes) which you would use to determine whether the other process has definitely finished with the file (e.g. not in the middle of reading or writing the other file).

wilsonsamm

Jmk wrote: »

Why not just try opening the file for reading? If it works then it exists.

Can two processes read the same file at once?

JamesW

Jmk wrote: »

Why not just try opening the file for reading? If it works then it exists. Or use findfirst() in an unusual manner, by specifying an exact file rather than a wildcard.

What if the file does exist, and a virus scanner has it open with an exclusive lock the moment you test?

For a lockfile, I guess you would just create a second file (zero-bytes) which you would use to determine whether the other process has definitely finished with the file (e.g. not in the middle of reading or writing the other file).

Operating systems provide a whole host of mechanisms for synchronising access to resources. Hacking up your own is likely to be poorer than using the ones provided.

Having said all that. Yes, there are holes in the plan, but if the OP is just hacking something up for fun, then it probably doesn't matter. Having said that, if you are hacking stuff up for fun, then it's probably more fun to try new stuff, and do it properly. As Winston has said, there is no need for hitting the disk for the OP's task. Do it properly. It'll be faster, more efficient (the file stuff smells of polling), and you'll learn something new.

wilsonsamm

Yeah, you are right. I don't need to hit the disk so I'm learning some pipe stuff now :)

I stayed away form perl, python & co, since they are scripted languages, and well, that's a bummer. I use Gentoo's portage, and I love this software, but IMHO the fact that it's written in python lets it down somewhat...

Winston

wilsonsamm wrote: »

I stayed away form perl, python & co, since they are scripted languages, and well, that's a bummer.

And what's wrong with that? (Or did you really want to say "interpreted" rather than scripted?)

For string wrangling, you aren't going to go much faster in C and you're going to take much, much longer writing the program in C than in a language which is built for text processing (not to mention all the defensive code you'll need write to prevent buffer overflows, something that's not a problem with python or perl). Perl at least has things like hashes and regular expressions as actually part of the language, which makes pattern matching and making lookup not only fast to execute but fast to program too, something you're going to be needing to do a lot of.

wilsonsamm

I deleted this since it was a double post.

wilsonsamm

Winston wrote: »

And what's wrong with that? (Or did you really want to say "interpreted" rather than scripted?)

Ah, then perhaps interpreted is what I meant. What does scripted mean, then? Well, I know that bash, perl, csh, and others are scripted, but come to think of it, I actually don't understand what this term means...
I started programming in GW BASIC (by Microsoft ? and the platform I did this on was a Rainbow 100 running MS-DOS 3.11). Interpreted, it was terribly slow, even with two processors running at 4 MHz. But father who knew Fortran and had a compiler and had an identical computer wrote much faster programs than I ever could :-) And since these days I've not liked interpreted languages much.

Perhaps I lack confidence... Now my processor is more than 200 times as fast and its load rarely is more than 20%...

JamesW

You can write scripts with perl/python/sh/etc. The program(s) controlled by the script is scripted. The languages themselves are not. The suggested languages for your task were perl and python. These are interpreted. Just like your old BASIC example, an interpreter will read the script line by line, executing each line as it goes. Unlike your old BASIC example, things have moved on a bit...

The interpreters can 'cheat' - the python interpreter will compile python to python byte code for example. This can result in faster code than a naive interpreter. Also machines are a lot faster now. Even if compiled C is faster does it matter if a task is completed in 0.01 seconds or 0.1 seconds? What does matter is that writing safe string manipulation code in perl or python will take far less time than in C.

Not that they will be slow either. Perl and python are very good at messing with strings. You will be hard pushed to beat their performance with C. Perl and python are eventually calling into C libraries to do their thing anyway.