tags:

views:

152

answers:

5

Can anyone point me to some discussion covering the pro's and con's of opening a file for read and write as opposed to (for example) opening a file for read, closing it and then reopening for write. I've tried searching for in-depth information without joy.

Many thanks

+5  A: 

It depends on what you're doing. Opening for read and write can be harder to get correct and consistent as it's very easy to accidentally truncate the file or overwrite parts of the data unintentionally.

If reading and then writing (presumably a complete replacement) is actually an option, then two separate file opens may well be simpler, but consider writing to a new file and renaming if successful to make sure that if something (even a programming error!) interrupts the write the old data isn't lost.

If you do decide to open for read/write make sure to read the documentation carefully so that you don't truncate the file on opening and take care with seek and tell functions. Unless you open in binary mode you can only safely pass to seek a position that was returned by a previous tell.

Charles Bailey
+1  A: 

Speed.

But it depends on what you're doing.

If you're going to write a lot of small things, it's better to keep it open.
If you're going to write a big chunk of data, it's (perhaps) better to load it every time you need it.

The same goes for reading.

knight666
+4  A: 

I would suggest the most plausible reason being race conditions.

Assume two users are going to access the same file and edit it. User A opens the file, reads it in and closes it. User B comes along before User A has had a chance to write and he also reads in the file.

Now if User A had left the file open User B could not access it to read. In many cases this is the desired behavior as it avoids any possible race conditions. User B cannot access the file till User A is done with it.

Alternatively, let us assume that Users A and B will not rewrite anything in the file but only append to it, and that the order in which they do so is unimportant (logging is a good example of this). In this case it makes sense for us to give User B access to the file before User A has written as User B maybe unconcerned with what User A is currently doing.

Obviously both cases are concerned with how you want to handle the race condition, so you should think about that problem first. Usually blocking behavior prevents race conditions from hurting your program, so I would default to that behavior, but be aware of the alternatives.

tzenes
No OS was mentioned so it's probably worth noting that Windows defaults to locking open files to prevent concurrent accesses, but Unix-like systems don't.
SimonJ
There are a number of mechanisms to support locking (though you're right the default does not), obviously in a non-locking case you'd have to utilize the dnotify mechanism (linux 2.4+) to deal with the race condition.
tzenes
+2  A: 

Since no one has mentioned it, I'll go with the obvious - because you want to read and write to the file at the same time.

Consider something like an ISAM file where you want to read, add, delete, replace records at various offsets, update the indexes, etc. A whole lot easier to do by seeking to proper places without opening and closing the files!

Duck
+1  A: 

Another thing that needs to be taken care of if you open the file for reading and writing is that you need to flush your stream while switching between read and write operations

Tanuj