Re: reliable update of a file
From: Eric Sosman (Eric.Sosman_at_sun.com)
Date: 11/05/03
- Next message: Steven Wong: "dbx debugging problem"
- Previous message: Christian Gollwitzer: "Re: seconds to YYYYMMDDHHMMSS"
- In reply to: Victor: "Re: reliable update of a file"
- Next in thread: Chuck Dillon: "Re: reliable update of a file"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 05 Nov 2003 11:41:44 -0500
Victor wrote:
>
> > If the file is small enough that you can afford to have
> > multiple versions lying around ("fairly limited in its extent"
> > suggests this might be so), why not write a new version at each
> > cycle, using a version-specific name?
> >
> > for (i = 0; i < num_test_cycles; i++) {
> > ...
> > sprintf (filename, "outfile.%d", i);
> > fp = fopen(filename, "w");
> > ...
> > }
> >
> > If you don't want to let zillions of these files pile up, you
> > could delete the `N-ago' file after writing the newest one, or
> > you could just use `i % N' instead of plain `i' in the sprintf().
>
> Thanks for the suggestion. If I keep N nice and small, e.g. 2, and
> use the i % N approach, I can simply ls -l in the directory and
> determine which file was touched most recently. My cycles will be at
> least one minute apart, so it would be very easy to determine which
> was newest in the event of a failure.
If you're going to use N=2, you might want to consider
a hard-coded method. At each cycle:
write to "outfile.tmp"
delete "outfile.bak"
rename "outfile.out" to "outfile.bak"
rename "outfile.tmp" to "outfile.out"
... bailing out if anything goes wrong (except that the second
and third steps are expected to fail on the very first cycle).
If you're worried about spending disk space for three copies,
however briefly, you could do the deletion of "outfile.bak"
first instead of second.
The advantage, of course, is that in the absence of failures
the latest output file has a constant name; no rummaging around
with timestamps is required. This may make things easier for
scripts and whatnot associated with the program.
Be sure to check *every* operation for success or failure:
fopen(), fprintf()/fwrite(), and even fclose()! You may find
the ferror() function handy, since it can check the cumulative
success or failure of all the output operations instead of
checking each one individually.
-- Eric.Sosman@sun.com
- Next message: Steven Wong: "dbx debugging problem"
- Previous message: Christian Gollwitzer: "Re: seconds to YYYYMMDDHHMMSS"
- In reply to: Victor: "Re: reliable update of a file"
- Next in thread: Chuck Dillon: "Re: reliable update of a file"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
