By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,154 Members | 1,024 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,154 IT Pros & Developers. It's quick & easy.

crash during file writing, how to recover ?

P: n/a
Hi
I'm writing a commercial program which must be reliable. It has to do
some basic reading and writing to and from files on the hard disk,
and also to a floppy.
I have foreseen a potential problem. The program may crash
unexpectedly while writing to the file. If so, my program should
detect this during startup, and then (during startup) probably delete the
data added to the file and redo the writing operation.

Are file writing operations atomic ? ie when you write to a file,
will it either do it succesfully, OR say half fail (eg write a few letters
and not finish), OR not commit any changes to the file if a crash at
this point occurs?

My next question is how is this handled in commercial programming? I
plan on writing a flag (say, a simple char) to another file (this
would signal that a file write is about to begin), and then
removing this char after the file writing operation is completed.
Then on startup i just check the flags. if flag hasn't been removed a
crash occurred, so have to open file and get rid of any garbage.

Has anyone done anything similar b4? if so how did you handle this
crash scenario. My application could totally stuff up if i don't
handle this right.

by the way, i'm using the java language and api. this might effect
how files are written to, so i thought i should mention this.
MANY THANKS
Joseph

Jul 17 '05 #1
Share this Question
Share on Google+
48 Replies


P: n/a
On Fri, 30 Apr 2004 01:36:56 GMT, Joseph <ka****@bigpond.com> wrote or
quoted :
Are file writing operations atomic ? ie when you write to a file,
will it either do it succesfully, OR say half fail (eg write a few letters
and not finish), OR not commit any changes to the file if a crash at
this point occurs?


Imagine a floppy being written. The power fails half way through
writing one of your tracks. You then have gibberish on your floppy.
Further the fat and directory are likely out of sync. When you use
CHKDSK /F it tries to fix this. The file contains gibberish. You
probably should bulk erase and reformat such a floppy.

A very easy way to detect the problem is to write small file before
you start. You do your thing, and on exit you erase the file. You
can do this to any app by doing the creating testing and deleting in
bat language.

When you start, you check for the presence of the file. If you see it
you assume the worst, and demand a restore from backup or whatever you
need to do to get going again safely.
--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
Jul 17 '05 #2

P: n/a
Liz

"Roedy Green" <se*@mindprod.com.invalid> wrote in message
news:45********************************@4ax.com...
On Fri, 30 Apr 2004 01:36:56 GMT, Joseph <ka****@bigpond.com> wrote or
quoted :
Are file writing operations atomic ? ie when you write to a file,
will it either do it succesfully, OR say half fail (eg write a few lettersand not finish), OR not commit any changes to the file if a crash at
this point occurs?


Imagine a floppy being written. The power fails half way through
writing one of your tracks. You then have gibberish on your floppy.
Further the fat and directory are likely out of sync. When you use
CHKDSK /F it tries to fix this. The file contains gibberish. You
probably should bulk erase and reformat such a floppy.

A very easy way to detect the problem is to write small file before
you start. You do your thing, and on exit you erase the file. You
can do this to any app by doing the creating testing and deleting in
bat language.

When you start, you check for the presence of the file. If you see it
you assume the worst, and demand a restore from backup or whatever you
need to do to get going again safely.
--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.


I had an interesting situation a few years ago. I was using stacker
on my hard disk since it was only 20 megabytes. And I happened to
be doing a squeeze type operation when my battery died. At the next
powerup, stacker gave a message on the screen that it discovered that
it crashed during a squeeze and proceeded to automatically clean up.
I was impressed.
Jul 17 '05 #3

P: n/a
Joseph wrote:
Hi
I'm writing a commercial program which must be reliable. It has to do
some basic reading and writing to and from files on the hard disk,
and also to a floppy.
I have foreseen a potential problem. The program may crash
unexpectedly while writing to the file. If so, my program should
detect this during startup, and then (during startup) probably delete the
data added to the file and redo the writing operation.

Are file writing operations atomic ? ie when you write to a file,
will it either do it succesfully, OR say half fail (eg write a few letters
and not finish), OR not commit any changes to the file if a crash at
this point occurs?

My next question is how is this handled in commercial programming? I
plan on writing a flag (say, a simple char) to another file (this
would signal that a file write is about to begin), and then
removing this char after the file writing operation is completed.
Then on startup i just check the flags. if flag hasn't been removed a
crash occurred, so have to open file and get rid of any garbage.

Has anyone done anything similar b4? if so how did you handle this
crash scenario. My application could totally stuff up if i don't
handle this right.

by the way, i'm using the java language and api. this might effect
how files are written to, so i thought i should mention this.


One approach is to write to a temporary file, then when writing has
completed successfully, and the file has been closed, rename the
temporary file to the target filename. That way you won't run out of
disk space either. If you need to overwrite an old file, delete it just
before renaming. If your program crashes during temporary file
creation, you'll be left with a damaged temp file that is never used
again - no big deal.

Calum
Jul 17 '05 #4

P: n/a
Always write to a new file and then delete the old one and rename the new.
Also, consider writing a journal file before writing to the new file so you
can at least "recover" what's missing.

Norm,

"Joseph" <ka****@bigpond.com> wrote in message
news:Y4***************@news-server.bigpond.net.au...
Hi
I'm writing a commercial program which must be reliable. It has to do
some basic reading and writing to and from files on the hard disk,
and also to a floppy.
I have foreseen a potential problem. The program may crash
unexpectedly while writing to the file. If so, my program should
detect this during startup, and then (during startup) probably delete the
data added to the file and redo the writing operation.

Are file writing operations atomic ? ie when you write to a file,
will it either do it succesfully, OR say half fail (eg write a few letters
and not finish), OR not commit any changes to the file if a crash at
this point occurs?

My next question is how is this handled in commercial programming? I
plan on writing a flag (say, a simple char) to another file (this
would signal that a file write is about to begin), and then
removing this char after the file writing operation is completed.
Then on startup i just check the flags. if flag hasn't been removed a
crash occurred, so have to open file and get rid of any garbage.

Has anyone done anything similar b4? if so how did you handle this
crash scenario. My application could totally stuff up if i don't
handle this right.

by the way, i'm using the java language and api. this might effect
how files are written to, so i thought i should mention this.
MANY THANKS
Joseph


Jul 17 '05 #5

P: n/a
Norm Dresner wrote:

Always write to a new file and then delete the old one and rename the new.


No need to delete the old one first. Renaming will
automatically delete the old file.

--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use ab***@mk.lir.dk and ka*****@mk.lir.dk
/* Would you like fries with that? */
Jul 17 '05 #6

P: n/a
Kasper Dupont wrote:
Norm Dresner wrote:
Always write to a new file and then delete the old one and rename the new.

No need to delete the old one first. Renaming will
automatically delete the old file.

often that will lead to a "cant rename, file already exists"
sort of error....
- nate

Jul 17 '05 #7

P: n/a
Nate Smith wrote:

Kasper Dupont wrote:
Norm Dresner wrote:
Always write to a new file and then delete the old one and rename the new.

No need to delete the old one first. Renaming will
automatically delete the old file.


often that will lead to a "cant rename, file already exists"
sort of error....


I'm pretty sure the posix standard requires rename to
atomically remove and replace the target if it already
exists. But I don't have access to the standard, so
somebody else will have to check.

And using rename to delete the file is the correct way
to do because of the atomic behavioure. Deleting the old
file before renaming would introduce a race condition.

--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use ab***@mk.lir.dk and ka*****@mk.lir.dk
/* Would you like fries with that? */
Jul 17 '05 #8

P: n/a
On Fri, 30 Apr 2004 18:25:02 +0200, Kasper Dupont
<ka*****@daimi.au.dk> wrote or quoted :
No need to delete the old one first. Renaming will
automatically delete the old file.


Here is the sort of code I use to rewrite the contents of a file.
// create a tempfile in the same directory as
// the input file we have just processed.
File tempfile = HunkIO.createTempFile ("temp", ".tmp",
fileBeingProcessed );
FileWriter emit = new FileWriter( tempfile );
emit.write( result );
emit.close();
// successfully created output in same directory as input,
// Now make it replace the input file.
fileBeingProcessed.delete();
tempfile.renameTo( fileBeingProcessed );

This effectively makes the tempfile disappear, but without the delete
it would not make the old version disappear. Or would it?

It would be nice to have the delete/rename atomic.
--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
Jul 17 '05 #9

P: n/a
Roedy Green wrote:

On Fri, 30 Apr 2004 18:25:02 +0200, Kasper Dupont
<ka*****@daimi.au.dk> wrote or quoted :
No need to delete the old one first. Renaming will
automatically delete the old file.
Here is the sort of code I use to rewrite the contents of a file.

// create a tempfile in the same directory as
// the input file we have just processed.
File tempfile = HunkIO.createTempFile ("temp", ".tmp",
fileBeingProcessed );
FileWriter emit = new FileWriter( tempfile );
emit.write( result );
emit.close();
// successfully created output in same directory as input,
// Now make it replace the input file.
fileBeingProcessed.delete();
tempfile.renameTo( fileBeingProcessed );


Well, I don't write java code I usually use C, so I don't
know exactly how those methods are implemented. But I
know it is impossible to delete a file using any kind of
handle, you need to use the name. So exactly what is the
meaning of `fileBeingProcessed.delete();'? Does it delete
whatever file has the name originally used to open
fileBeingProcessed?

In the next line it looks like fileBeingProcessed is a
string, but then you wouldn't be able to delete the file
the way it is done in the code.

This effectively makes the tempfile disappear, but without the delete
it would not make the old version disappear. Or would it?
If the renameTo method calls the rename system call, it
will make the old file disappear.

It would be nice to have the delete/rename atomic.


You have it. At least on any posix compliant system you do.

--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use ab***@mk.lir.dk and ka*****@mk.lir.dk
/* Would you like fries with that? */
Jul 17 '05 #10

P: n/a
On Fri, 30 Apr 2004 21:12:36 +0200, Kasper Dupont
<ka*****@daimi.au.dk> wrote or quoted :
`fileBeingProcessed.delete();'? Does it delete
whatever file has the name originally used to open
fileBeingProcessed?


fileBeingProcessed is of type File. See
http://mindprod.com/jgloss/file.html

It contains a partly parsed filename. It is NOT a handle to an open
file as in C.
--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
Jul 17 '05 #11

P: n/a
Joseph wrote:

<snipped>
My next question is how is this handled in commercial programming? I
plan on writing a flag (say, a simple char) to another file (this
would signal that a file write is about to begin), and then
removing this char after the file writing operation is completed.
Then on startup i just check the flags. if flag hasn't been removed a
crash occurred, so have to open file and get rid of any garbage.


Why not just write your 'dirty flag' in the same file?

<snipped>

goose
Jul 17 '05 #12

P: n/a
Joseph wrote:
Hi
I'm writing a commercial program which must be reliable. It has to do
some basic reading and writing to and from files on the hard disk,
and also to a floppy.
I have foreseen a potential problem. The program may crash
unexpectedly while writing to the file. If so, my program should
detect this during startup, and then (during startup) probably delete the
data added to the file and redo the writing operation.

Are file writing operations atomic ? ie when you write to a file,
will it either do it succesfully, OR say half fail (eg write a few letters
and not finish), OR not commit any changes to the file if a crash at
this point occurs?

My next question is how is this handled in commercial programming? I
plan on writing a flag (say, a simple char) to another file (this
would signal that a file write is about to begin), and then
removing this char after the file writing operation is completed.
Then on startup i just check the flags. if flag hasn't been removed a
crash occurred, so have to open file and get rid of any garbage.

Has anyone done anything similar b4? if so how did you handle this
crash scenario. My application could totally stuff up if i don't
handle this right.

by the way, i'm using the java language and api. this might effect
how files are written to, so i thought i should mention this.
MANY THANKS
Joseph


Just another followup, possibly about a condition that
you have not considered.

Do you need to guard against a hard-disk crash while
writing? If your program does not, by some definitions
this is "not reliable." (Is restoring from "last
week's backup" OK with the customer?)

You can only guard against a single hardware failure
at a time. As I mentioned elsethread, DBMS's use
a log file to log the changes. This log file must
be on a separate hardware device to guard against
a single hardware failure. Thus, either the logfile
or the data file survives. If the logfile is on the
device that fails, then, no problem. If the data-file
is on the device that fails, it may be reconstructed
from the last backup of the data files and applying
all the log-files since the backup.

I am not sure if the "rename" strategy mentioned by
other posters will be atomic over multiple physical
devices nor do I know about what size files you
are talking about. If it's several GB, then the
copy from one disk to another will take considerable
time. Then again, you may not need to be at this
level of paranoia. :)

--
"It is impossible to make anything foolproof
because fools are so ingenious"
- A. Bloch
Jul 17 '05 #13

P: n/a
Nick Landsberg wrote:

You can only guard against a single hardware failure
at a time.
Actually you can guard against multiple hardware
failures, but it will get expensive.

I am not sure if the "rename" strategy mentioned by
other posters will be atomic over multiple physical
devices


That depends. If you use a filesystem on a raid it
should be atomic. But raid is not 100% safe. With
an unfortunate sequence of events even a raid will
lose data. If we are talking independent filesystems
the rename will just report an error.

--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use ab***@mk.lir.dk and ka*****@mk.lir.dk
/* Would you like fries with that? */
Jul 17 '05 #14

P: n/a
Kasper Dupont wrote:
Nick Landsberg wrote:
You can only guard against a single hardware failure
at a time.

Actually you can guard against multiple hardware
failures, but it will get expensive.


True. I inadvertantly left the word
"economically".
I am not sure if the "rename" strategy mentioned by
other posters will be atomic over multiple physical
devices

That depends. If you use a filesystem on a raid it
should be atomic. But raid is not 100% safe. With
an unfortunate sequence of events even a raid will
lose data. If we are talking independent filesystems
the rename will just report an error.

--
"It is impossible to make anything foolproof
because fools are so ingenious"
- A. Bloch
Jul 17 '05 #15

P: n/a
In article <40***************@daimi.au.dk>, Kasper Dupont <ka*****@daimi.au.dk> wrote:
I'm pretty sure the posix standard requires rename to
atomically remove and replace the target if it already
exists. But I don't have access to the standard, so
somebody else will have to check.

And using rename to delete the file is the correct way
to do because of the atomic behavioure. Deleting the old
file before renaming would introduce a race condition.


That sounds like a dangerous approach to me.

Why not rename the old file *first*, before writing the new one. Then
if the program starts and finds the most recently written file is
corrupt due to a crash, the last good file remains as a backup.
Renaming an existing file should be quick, and you can wait until it's
done before starting to write.

- Gerry Quinn

Jul 17 '05 #16

P: n/a
For the most part, I think this thread demonstrates confusion caused by
cross-posting. We've got answers from people in
comp.lang.java.programmer answering as if this were entirely a Java
question and people from comp.os.linux.development.apps answering as if
it's a Linux question... and we don't know who's right!

Nevertheless, some clarification about Java:

Kasper Dupont wrote:
Well, I don't write java code I usually use C, so I don't
know exactly how those methods are implemented. But I
know it is impossible to delete a file using any kind of
handle, you need to use the name. So exactly what is the
meaning of `fileBeingProcessed.delete();'? Does it delete
whatever file has the name originally used to open
fileBeingProcessed?

In the next line it looks like fileBeingProcessed is a
string, but then you wouldn't be able to delete the file
the way it is done in the code.
Java's standard API class java.io.File is confusingly named. It
represents an abstract path name, not a file. Having a java.io.File
object doesn't even imply the existence of a file in the filesystem,
though File does expose an API method called exists() that tells you
whether this file exists in the filesystem or not. Certain operations
that deal with directory management (rename, delete, etc.) are
implemented for objects of the File class. So Roedy's calls make
perfect sense because they don't operate on a file descriptor, but
rather on a file name.
If the renameTo method calls the rename system call, it
will make the old file disappear.


Not surprisingly, it's not specified whether File.renameTo results in a
call to the rename system call. More surprisingly, it's not specified
whether File.renameTo will succeed if a file already exists by the
target name. That said, renameTo returns a success flag (which is ugly
in Java, but nevertheless happens). So it's entirely possible to write:

if (!newFile.renameTo(fileBeingProcessed))
{
fileBeingProcessed.delete();
newFile.renameTo(fileBeingProcessed);
}

Additional error checking would be nice in case the rename fails, for
example, on a Windows machine because of open file descriptors to the
file. Windows file handling doesn't separate the existence of a file
from its directory entry in the way POSIX does.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
Jul 17 '05 #17

P: n/a
Gerry Quinn wrote:

In article <40***************@daimi.au.dk>, Kasper Dupont <ka*****@daimi.au.dk> wrote:
I'm pretty sure the posix standard requires rename to
atomically remove and replace the target if it already
exists. But I don't have access to the standard, so
somebody else will have to check.
I just checked susv3 does require rename to make
sure at any point in time, the target name will
refere to either the old or the new file. And if
rename fails the target must be unaffected.

And using rename to delete the file is the correct way
to do because of the atomic behavioure. Deleting the old
file before renaming would introduce a race condition.


That sounds like a dangerous approach to me.

Why not rename the old file *first*, before writing the new one. Then
if the program starts and finds the most recently written file is
corrupt due to a crash, the last good file remains as a backup.
Renaming an existing file should be quick, and you can wait until it's
done before starting to write.


But then you'd have a window where no file exist with
the given name. The approach I suggested is safe. When
creating the new file first create it with a different
name. And when you have finished writing you rename it
such that it atomically replaces the old file.

There is nothing dangerous to it.

--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use ab***@mk.lir.dk and ka*****@mk.lir.dk
/* Would you like fries with that? */
Jul 17 '05 #18

P: n/a
Chris Smith wrote:

Not surprisingly, it's not specified whether File.renameTo results in a
call to the rename system call. More surprisingly, it's not specified
whether File.renameTo will succeed if a file already exists by the
target name.


Well I don't know anything about Java. But I know that
the right way to do this requires use of the rename
system call to atomically remove the old file and
replace it with the new. If that is not what happens it
means either the Java program or the Java VM is broken.

--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use ab***@mk.lir.dk and ka*****@mk.lir.dk
/* Would you like fries with that? */
Jul 17 '05 #19

P: n/a
Gerry Quinn wrote:
Kasper Dupont <ka*****@daimi.au.dk> wrote:
I'm pretty sure the posix standard requires rename to
atomically remove and replace the target if it already
exists. But I don't have access to the standard, so
somebody else will have to check.

And using rename to delete the file is the correct way
to do because of the atomic behavioure. Deleting the old
file before renaming would introduce a race condition.


That sounds like a dangerous approach to me.

Why not rename the old file *first*, before writing the new one.
Then if the program starts and finds the most recently written
file is corrupt due to a crash, the last good file remains as a
backup. Renaming an existing file should be quick, and you can
wait until it's done before starting to write.


That is not his point. If a rename can fail because the target
file pre-exists, the delete/rename sequence has a hole between
delete and rename in which some other process can create that file
name, and cause a failure. This is a race condition. It is
especially likely to occur with database systems which inherently
tend to service multiple processes from the same database, and
have to 'take steps' to ensure the self-consistency of that
database.

One cure is to provide atomic operations, often by the use of
critical sections or other synchronization primitives. Another is
the concept of 'transactions'.

--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Jul 17 '05 #20

P: n/a
what about using copy first?
and what about exclusive access?

outline:
---------------------------------------------------------

actually first, grab the oldFile exclusively
if successful
then
open oldFile for Read
open saveFile for Write

copy oldFile to saveFile

close oldFile
close saveFile

if copy was successful
then
open oldFile for Write
open saveFile for Read

do the cloudy processing thing that rewrites oldFile
from the saveFile stuff & the "new stuff", whatever
the new stuff is (the changes, updates, etc.)

close oldFile
close saveFile

in case of crash in middle, saveFile should have the recovery
or if the copy step failed, oldFile is still unchanged,
and politely notify any interested parties

now release the exclusive hold on oldFile & let the race resume

else
wait until can grab oldFile exclusively in time,
where some waiting period has been established
to quit trying, and try again a "second" later
or
in case of time out, notify interested parties and
maybe quit thread with flag (duck out of the race)

NOTE:
presumably there are already other things in place elsewhere
that preserve the "new stuff" (changes, etc.) through crashes

-------------------------------------------------------------------

- nate, trying to keep from spilling his white russian

Jul 17 '05 #21

P: n/a
Chris Smith wrote:
Not surprisingly, it's not specified whether File.renameTo results in a
call to the rename system call. More surprisingly, it's not specified
whether File.renameTo will succeed if a file already exists by the
target name. That said, renameTo returns a success flag (which is ugly
in Java, but nevertheless happens). So it's entirely possible to write:

if (!newFile.renameTo(fileBeingProcessed))
{
fileBeingProcessed.delete();
newFile.renameTo(fileBeingProcessed);
}


Just to be inconsistent, the Microsoft "rename" function specifically
requires "The new name must not be the name of an existing file or
directory". It makes some sense - I wouldn't expect a function called
"rename" to delete a file, but I can see situations where either
behaviour would be desired.

So it's possible Java will have different behaviour on Windows and
POSIX, though I can't be bothered to check this.

I guess for ultra-safety, the old file could be renamed to something
else, before renaming the new file to the target filename. Of course
then you'd just clutter up the directory with old files, but there are
circumstances where you want to be able to roll back.

Calum
Jul 17 '05 #22

P: n/a
On Sat, 01 May 2004 23:59:52 +0100, Calum <ca********@ntlworld.com>
wrote or quoted :

I guess for ultra-safety, the old file could be renamed to something
else, before renaming the new file to the target filename. Of course
then you'd just clutter up the directory with old files, but there are
circumstances where you want to be able to roll back.

The problem is a lack of naming convention for temporary file.

If at least Java could name all temps in a standard way, some tool
such as batik could periodically cleanup the trash left over from
crashes.

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
Jul 17 '05 #23

P: n/a
"goose" <ru**@webmail.co.za> wrote in message
news:40**************@webmail.co.za...
Joseph wrote:

<snipped>
My next question is how is this handled in commercial programming? I
plan on writing a flag (say, a simple char) to another file (this
would signal that a file write is about to begin), and then
removing this char after the file writing operation is completed.
Then on startup i just check the flags. if flag hasn't been removed a
crash occurred, so have to open file and get rid of any garbage.


Why not just write your 'dirty flag' in the same file?

Because if the power fails during this write-op, the entire track of the
media may be lost.

The real question is, what else do you need to hold up your pants
besides a belt and suspenders?

Norm

Jul 17 '05 #24

P: n/a
Norm Dresner wrote:
"goose" <ru**@webmail.co.za> wrote in message
news:40**************@webmail.co.za...
Joseph wrote:

<snipped>
My next question is how is this handled in commercial programming? I
plan on writing a flag (say, a simple char) to another file (this
would signal that a file write is about to begin), and then
removing this char after the file writing operation is completed.
Then on startup i just check the flags. if flag hasn't been removed a
crash occurred, so have to open file and get rid of any garbage.


Why not just write your 'dirty flag' in the same file?


Because if the power fails during this write-op, the entire track of the
media may be lost.

The real question is, what else do you need to hold up your pants
besides a belt and suspenders?

Norm


Well, that depends Norm:)

How critical is that data? How much is the customer
willing to pay to ensure data integrity and consistency?

How does the customer define "reliabilty" for the OP's
application? Have they quantified it? ("Never losing
any data" is not a reasonable requirement. "Never"
is not a number.) If it's something like "no more than 3
records per 1,000,000 are allowed to be lost", how
will this be validated/tested? At what cost?
What is the test plan? What is the probability
of a hardware outage (on this specific hardware)?
What is the probability of a software bug scribbling
all over the data? (Suggestions about keeping a
previous copy of "good" data address a part of this
problem.) How do you validate any particular
data file at startup? How long will it take?
How long will it take to bring it up to date?
(Is it necessary to bring it up to date, or is
last night's copy ok?)

All of these questions (and more) may have
to be answered before the final
solution is decided upon. Everytime you kick
up the requirement a notch, the development (not just
coding) cost usually goes up proportionately,
which brings us back to "how much is the
customer willing to pay?"

<War Story>

I have heard of (but not personally worked on) a system
where the customer *insisted* on triple-mirroring
(primary and 3 copies). Each string was on a separate
controller and on a separate UPS. Each "CPU-box" was also
duplicated and on a separate UPS and could take over the
processing in case of a single CPU failure. All data was also
replicated to a remote site which could pick up the
load in case of a real disaster (e.g. tornado or
earthquake ... yep, one of the data centers was sitting
right smack dab on the Hayward Fault, the other was
in Kansas... go figure).

(As you may have intuited, this was a *financial* application
with some ungodly number of transactions per hour.
The bean counters get apoplectic when they lose track
of a few cents here of there. To me, this was
an extreme case of overkill, but the customer
was willing to pay for it. This may also give you
some clue as to why your credit card interest
rates are so high :)

</War Story>

It is highly doubtful that the OP needs this kind
of fault tolerance or fault recovery, but we
really don't know the customer's requirements.

--
"It is impossible to make anything foolproof
because fools are so ingenious"
- A. Bloch
Jul 17 '05 #25

P: n/a
Calum wrote:
Chris Smith wrote:
Not surprisingly, it's not specified whether File.renameTo results in
a call to the rename system call. More surprisingly, it's not
specified whether File.renameTo will succeed if a file already exists
by the target name. That said, renameTo returns a success flag (which
is ugly in Java, but nevertheless happens). So it's entirely possible
to write:

if (!newFile.renameTo(fileBeingProcessed))
{
fileBeingProcessed.delete();
newFile.renameTo(fileBeingProcessed);
}


Just to be inconsistent, the Microsoft "rename" function specifically
requires "The new name must not be the name of an existing file or
directory". It makes some sense - I wouldn't expect a function called
"rename" to delete a file, but I can see situations where either
behaviour would be desired.


The Win32 API supplies MoveFile() and MoveFileEx().

MoveFile() will fail if the destination exists, or if you're trying to
move a directory to another device.

MoveFileEx() allows you to specify a number of options, including an
option to replace an existing file.

Of course MoveFileEx() isn't available on Win9x/Me...

Another option is to copy oldfile to backup, open oldfile for writing,
replace its contents with newfile, close everything and delete backup
and newfile. While far from being atomic, it is recoverable. If the
operation fails at any point you still have the files (oldfile and
newfile) in one form or another.

Of course if you're talking about a multi-gigabyte data store, this is
gonna take a while :>

--
Corey Murtagh
The Electric Monk
"Quidquid latine dictum sit, altum viditur!"
Jul 17 '05 #26

P: n/a
your talking about a forward error recovery pattern.
check out the design philosophy of POET, the object database engine that
used a technique that's known as Jounalizing under Linux today.
Essentially, they maintained a separate "Ledger" that tracked all
transactions to the objectdatabase and if for any reason on a restart
that that ledger was found out of sync or not properly closed, they knew
there was unfinished work with the object file.

- perry
Corey Murtagh wrote:
Calum wrote:
Chris Smith wrote:
Not surprisingly, it's not specified whether File.renameTo results in
a call to the rename system call. More surprisingly, it's not
specified whether File.renameTo will succeed if a file already exists
by the target name. That said, renameTo returns a success flag
(which is ugly in Java, but nevertheless happens). So it's entirely
possible to write:

if (!newFile.renameTo(fileBeingProcessed))
{
fileBeingProcessed.delete();
newFile.renameTo(fileBeingProcessed);
}

Just to be inconsistent, the Microsoft "rename" function specifically
requires "The new name must not be the name of an existing file or
directory". It makes some sense - I wouldn't expect a function called
"rename" to delete a file, but I can see situations where either
behaviour would be desired.

The Win32 API supplies MoveFile() and MoveFileEx().

MoveFile() will fail if the destination exists, or if you're trying to
move a directory to another device.

MoveFileEx() allows you to specify a number of options, including an
option to replace an existing file.

Of course MoveFileEx() isn't available on Win9x/Me...

Another option is to copy oldfile to backup, open oldfile for writing,
replace its contents with newfile, close everything and delete backup
and newfile. While far from being atomic, it is recoverable. If the
operation fails at any point you still have the files (oldfile and
newfile) in one form or another.

Of course if you're talking about a multi-gigabyte data store, this is
gonna take a while :>


Jul 17 '05 #27

P: n/a
In article <40***************@daimi.au.dk>, Kasper Dupont <ka*****@daimi.au.dk> wrote:
Gerry Quinn wrote:

In article <40***************@daimi.au.dk>, Kasper Dupont

<ka*****@daimi.au.dk> wrote:
>I'm pretty sure the posix standard requires rename to
>atomically remove and replace the target if it already
>exists. But I don't have access to the standard, so
>somebody else will have to check.
I just checked susv3 does require rename to make
sure at any point in time, the target name will
refere to either the old or the new file. And if
rename fails the target must be unaffected.


Well, that justifies your approach, so.
Why not rename the old file *first*, before writing the new one. Then
if the program starts and finds the most recently written file is
corrupt due to a crash, the last good file remains as a backup.
Renaming an existing file should be quick, and you can wait until it's
done before starting to write.


But then you'd have a window where no file exist with
the given name. The approach I suggested is safe. When
creating the new file first create it with a different
name. And when you have finished writing you rename it
such that it atomically replaces the old file.

There is nothing dangerous to it.


Given the above guarantee (which probably means the OS does something
like I was suggesting!)

The window where no file exists is not a problem because software knows
what the alternative name for the original file is, if the proper file
is corrupt or non-existent.

- Gerry Quinn



Jul 17 '05 #28

P: n/a

Hi all

I'm thankful to everyone for sharing their opinion. I read everybody's post
and learned allot. It turns out that my algorithm will be simple, maybe
something like this:
Make a copy of existing data_file in the same directory

operate on this new copy (data_file2) to add data

close data_file2 when done

delete data_file (original)

rename data_file2 to data_file


on startup the sw will be able to detect if a crash occurred and respond
appropriately. The code on startup should be pretty straight forward

By the way, the platform is java on linux (probably red hat)

Joseph


Jul 17 '05 #29

P: n/a
Calum wrote:
Just to be inconsistent, the Microsoft "rename" function
specifically requires "The new name must not be the name
of an existing file or directory". It makes some sense - I
wouldn't expect a function called "rename" to delete a file,
but I can see situations where either behaviour would be desired.


I can't. You should *NOT* be able to rename/mv a file ONTOP of
an existing file (IMO, obviously).

I've always considered the unice ability to do so one of those
razor-sharp pointy bits you need to be very, very careful about.

--
|_ CJSonnack <Ch***@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL |
|_____________________________________________|___ ____________________|
Jul 17 '05 #30

P: n/a
Nick Landsberg wrote:
The bean counters get apoplectic when they lose track
of a few cents here of there. To me, this was
an extreme case of overkill, but the customer
was willing to pay for it.


Personally, this is a level of overkill I'm glad my bank and
CC companies indulge in.

Maybe YOU don't mind if a few cents disappear from your accounts,
but it makes ME apoplectic! (-:

--
|_ CJSonnack <Ch***@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL |
|_____________________________________________|___ ____________________|
Jul 17 '05 #31

P: n/a
Chris Sonnack wrote:
Nick Landsberg wrote:

The bean counters get apoplectic when they lose track
of a few cents here of there. To me, this was
an extreme case of overkill, but the customer
was willing to pay for it.

Personally, this is a level of overkill I'm glad my bank and
CC companies indulge in.

Maybe YOU don't mind if a few cents disappear from your accounts,
but it makes ME apoplectic! (-:


I was referring to the triple mirroring when
I used the word overkill. :) I would
agree with you that I, too, would get upset
if my bank balance was wrong. The triple
mirroring was /their/ preconcieved solution
to the problem which could have been solved
more cheaply.

--
"It is impossible to make anything foolproof
because fools are so ingenious"
- A. Bloch
Jul 17 '05 #32

P: n/a
Nick Landsberg wrote:

I was referring to the triple mirroring when
I used the word overkill. :) I would
agree with you that I, too, would get upset
if my bank balance was wrong. The triple
mirroring was /their/ preconcieved solution
to the problem which could have been solved
more cheaply.


Actually a bank in Denmark recently introduced a system
with three mirrors. That happened after IBM screwed up
their system with only two copies of the data. IIRC the
bank had to pay around 10 million dollars in expenses to
their customers.

--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use ab***@mk.lir.dk and ka*****@mk.lir.dk
I'd rather be a hammer than a nail.
Jul 17 '05 #33

P: n/a
On Mon, 03 May 2004 22:42:47 +0200, Kasper Dupont
<ka*****@daimi.au.dk> wrote or quoted :
Actually a bank in Denmark recently introduced a system
with three mirrors. That happened after IBM screwed up
their system with only two copies of the data. IIRC the
bank had to pay around 10 million dollars in expenses to
their customers.


If you really wanted to be safe, you have three teams running it and
three programming teams working to the same spec.

I was watching a Sun video the other day where the Sun guy was saying
with a flick of his mouse he could install software on 1000 servers.

On the other hand, he could bring 1000 servers to their knees with a
flick of his mouse.

Must feel like Bush toying with the big red button.
--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
Jul 17 '05 #34

P: n/a
Chris Sonnack wrote:
Nick Landsberg wrote:
The bean counters get apoplectic when they lose track
of a few cents here of there. To me, this was
an extreme case of overkill, but the customer
was willing to pay for it.


Personally, this is a level of overkill I'm glad my bank and
CC companies indulge in.

Maybe YOU don't mind if a few cents disappear from your accounts,
but it makes ME apoplectic! (-:


Actually, I have no objection whatsoever to a few cents
disappearing from your accounts, with the sole proviso that they
reappear in mine.

--
"I'm a war president. I make decisions here in the Oval Office
in foreign policy matters with war on my mind." - Bush.
"Churchill and Bush can both be considered wartime leaders, just
as Secretariat and Mr Ed were both horses." - James Rhodes.
Jul 17 '05 #35

P: n/a
Kasper Dupont wrote:
Nick Landsberg wrote:
I was referring to the triple mirroring when
I used the word overkill. :) I would
agree with you that I, too, would get upset
if my bank balance was wrong. The triple
mirroring was /their/ preconcieved solution
to the problem which could have been solved
more cheaply.

Actually a bank in Denmark recently introduced a system
with three mirrors. That happened after IBM screwed up
their system with only two copies of the data. IIRC the
bank had to pay around 10 million dollars in expenses to
their customers.


Three mirrors implies four copies.

There are two situations which could
have cause the problem, one of which is
*probably* not IBM's fault. For example,
a disk goes off-line because of a hardware
failure. Diagnostics are issued, but the
customer does not immediately take steps
to replace that disk. If the customer
waits a week or more to replace it, they
are "at risk" of another disk failure
during that time period, all the more so
if all the disks were from the same
batch. I am no apologist for IBM, and
I do not know all the details of this situation
so this is just conjecture on my part.
(But I have seen it happen in the past.)

The other situation is when a software bug
scribbles all over the data. In this case,
it will scribble over *all* copies of the
data. Adding additional disks does not
solve this problem. :)
--
"It is impossible to make anything foolproof
because fools are so ingenious"
- A. Bloch
Jul 17 '05 #36

P: n/a
CBFalconer wrote:
Chris Sonnack wrote:
Nick Landsberg wrote:

The bean counters get apoplectic when they lose track
of a few cents here of there. To me, this was
an extreme case of overkill, but the customer
was willing to pay for it.


Personally, this is a level of overkill I'm glad my bank and
CC companies indulge in.

Maybe YOU don't mind if a few cents disappear from your accounts,
but it makes ME apoplectic! (-:

Actually, I have no objection whatsoever to a few cents
disappearing from your accounts, with the sole proviso that they
reappear in mine.


Wasn't this the case in one of the "urban legends"
of the early days of computers?

What I remember (and memory is the second thing
to go) is that there was a story about some bank
customer who computed what his compound interest
should have been and found it to be a few pennies
off. (This was in the days before calculators.)
He went to his local bank branch and confronted
them with the data. After checking his data,
they confirmed that he was right. They subsequently
found that the person who had programmed their
system had taken the "breakage" (fractions of cents)
and had it credited to his account. This
amounted to quite a bundle!

I do not know if this story is true, just
relating it as a piece of trivia/memorobilia.

Were you that person, Chuck? :)

--
"It is impossible to make anything foolproof
because fools are so ingenious"
- A. Bloch
Jul 17 '05 #37

P: n/a
Nick Landsberg wrote:
CBFalconer wrote:
Chris Sonnack wrote:
Nick Landsberg wrote:

The bean counters get apoplectic when they lose track
of a few cents here of there. To me, this was
an extreme case of overkill, but the customer
was willing to pay for it.

Personally, this is a level of overkill I'm glad my bank and
CC companies indulge in.

Maybe YOU don't mind if a few cents disappear from your accounts,
but it makes ME apoplectic! (-:


Actually, I have no objection whatsoever to a few cents
disappearing from your accounts, with the sole proviso that they
reappear in mine.


Wasn't this the case in one of the "urban legends"
of the early days of computers?

What I remember (and memory is the second thing
to go) is that there was a story about some bank
customer who computed what his compound interest
should have been and found it to be a few pennies
off. (This was in the days before calculators.)
He went to his local bank branch and confronted
them with the data. After checking his data,
they confirmed that he was right. They subsequently
found that the person who had programmed their
system had taken the "breakage" (fractions of cents)
and had it credited to his account. This
amounted to quite a bundle!

I do not know if this story is true, just
relating it as a piece of trivia/memorobilia.

Were you that person, Chuck? :)


Unfortunately, no. However it goes on today, and is known as
'float'. When some bill handling firm receives your payment to
JoesFancyGrocery, they age it for some period of time, collecting
the interest (which may be only one day) and then forward the
original amount.

A better technique (for your tale) would be to have taken
advantage of the bias in rounding. In the US we round 0.50..0 of
anything up to 1.0, which produces a bias of some size. If the
perpetrator had been satisfied with this he might still be
collecting. Rounding down also produces a bias, while round to
even is (normally) unbiased.

--
"I'm a war president. I make decisions here in the Oval Office
in foreign policy matters with war on my mind." - Bush.
"Churchill and Bush can both be considered wartime leaders, just
as Secretariat and Mr Ed were both horses." - James Rhodes.

Jul 17 '05 #38

P: n/a
On Mon, 03 May 2004 22:05:22 GMT, Nick Landsberg
<hu*****@NOSPAM.att.net> wrote or quoted :
The other situation is when a software bug
scribbles all over the data. In this case,
it will scribble over *all* copies of the
data. Adding additional disks does not
solve this problem. :)


The scariest sort of software bug is one that corrupts data just a
tiny bit so that problem may not be noticed for a long time. By the
all the back ups are corrupt too.

All you could is find a very old database and play transactions
against it, or write some one-shot program to compensate for the
trouble.

In banking it would be catastrophic since you have already sent out
erroneous statements.

The RZ-1000 DMA controller hardware bug was horrible for this same
reason. The corruption was sporadic and minor.
--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
Jul 17 '05 #39

P: n/a
On Mon, 03 May 2004 22:13:32 GMT, Nick Landsberg
<hu*****@NOSPAM.att.net> wrote or quoted :
I do not know if this story is true, just
relating it as a piece of trivia/memorobilia.


Everybody heard the story if you were around in computing circa 1962.

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
Jul 17 '05 #40

P: n/a
Nick Landsberg wrote:

There are two situations which could
have cause the problem, one of which is
*probably* not IBM's fault.


I don't know the details. But multiple people knowing
more details than me have told, that there is no doubt it
was IBM's fault. If I understood it correctly, it happened
as some IBM technical personel was doing some maintainance
on the system. And it also sounded like some software bug
in the database must have been part of the reason.

Later IBM actually payed part of the 10 million dollars of
damages. Though I think the exact amount IBM payed in this
case is kept secret.

--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use ab***@mk.lir.dk and ka*****@mk.lir.dk
I'd rather be a hammer than a nail.
Jul 17 '05 #41

P: n/a
On Tue, 04 May 2004 02:01:06 GMT, CBFalconer <cb********@yahoo.com>
wrote:
Nick Landsberg wrote:

Were you that person, Chuck? :)


Unfortunately, no.


Hm, I thought everyone knew it was Richard Pryor ;^D

Darko
Jul 17 '05 #42

P: n/a
Roedy Green wrote:
If you really wanted to be safe, you have three teams running it and
three programming teams working to the same spec.


Indeed. Failing to do this brought down the EMS coordination system in
Berlin during the millenium change. IIRC it was a bug indirectly related to
the Y2K problem. They had a mirror. Which exactly replicated the bug.
Then they switched back to their old system. Which couldn't handle the
load of emergencies generated by 4 Million people partying...
Jul 17 '05 #43

P: n/a
[ egregious cross-posting elided ]

Joseph <ka****@bigpond.com> wrote:
I'm thankful to everyone for sharing their opinion. I read
everybody's post and learned allot. It turns out that my algorithm
will be simple, maybe something like this:

Make a copy of existing data_file in the same directory
operate on this new copy (data_file2) to add data
close data_file2 when done
delete data_file (original)
rename data_file2 to data_file

on startup the sw will be able to detect if a crash occurred and
respond appropriately. The code on startup should be pretty
straight forward

By the way, the platform is java on linux (probably red hat)


Since you're on Linux, you can eliminate the fourth step.
File.renameTo() fails on Windows if the destination exists, but it's
fine on Unix. That way, you don't need any special startup logic at
all; rename() on Unix between files in the same directory (actually,
filesystem) is guaranteed to be atomic. However, if your code needs
to run on Windows, you need what you described above.

BTW, I asked once on a Microsoft group whether MoveFile() is
guaranteed to be atomic on Windows between names on the same
filesystem, like rename() in POSIX. Unfortunately, I didn't get
anything definitive, just a lot of mumbling that amounted to
"probably, as long as you're on NTFS." Any Windows gurus here that
know if there is such a guarantee (or that it is specifically *not*
guaranteed)?

-- Lucas
Jul 17 '05 #44

P: n/a
CBFalconer wrote:
In the US we round 0.50..0 of anything up to 1.0, which produces
a bias of some size. If the perpetrator had been satisfied with
this he might still be collecting. Rounding down also produces
a bias, while round to even is (normally) unbiased.


Isn't "Banker's Rounding" rounding to even (or similar)?

--
|_ CJSonnack <Ch***@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL |
|_____________________________________________|___ ____________________|
Jul 17 '05 #45

P: n/a
Hi
So just to confirm, if the OS crashes while doing a rename file or delete
operation, the files being renamed or deleted can't be corrupted right (ie
these operations are atomic) ? Just want to be 100 percent sure.

And, if my temp file is corrupted, i wont be able to write to it. However,
it's possible to detect corrupted files using java api fuctions. I'll be
able to detect any corrupted file and simply delete it.

I know i'm asking alot of questions which have pretty much been answered,
but I'd like to feel more sure about all this.

thanks

Joseph
Joseph wrote:

Hi all

I'm thankful to everyone for sharing their opinion. I read everybody's
post
and learned allot. It turns out that my algorithm will be simple, maybe
something like this:
Make a copy of existing data_file in the same directory

operate on this new copy (data_file2) to add data

close data_file2 when done

delete data_file (original)

rename data_file2 to data_file


on startup the sw will be able to detect if a crash occurred and respond
appropriately. The code on startup should be pretty straight forward

By the way, the platform is java on linux (probably red hat)

Joseph


Jul 17 '05 #46

P: n/a
Liz

"Joseph" <ka****@bigpond.com> wrote in message
news:qi******************@news-server.bigpond.net.au...
Hi
So just to confirm, if the OS crashes while doing a rename file or delete
operation, the files being renamed or deleted can't be corrupted right (ie
these operations are atomic) ? Just want to be 100 percent sure.
I have not read all the preceding emails but I was
just reading a java book last night and it says to
write the file to a temp file first then do a copy
as a single operation. If the crash occurs:
1. writing temp -> the old official file is still good
2. during the copy -> the temp is still good
you probably have to figure out 1 or 2 manually during
the crash recovery

And, if my temp file is corrupted, i wont be able to write to it. However, it's possible to detect corrupted files using java api fuctions. I'll be
able to detect any corrupted file and simply delete it.

I know i'm asking alot of questions which have pretty much been answered,
but I'd like to feel more sure about all this.

thanks

Joseph
Joseph wrote:

Hi all

I'm thankful to everyone for sharing their opinion. I read everybody's
post
and learned allot. It turns out that my algorithm will be simple, maybe
something like this:
Make a copy of existing data_file in the same directory

operate on this new copy (data_file2) to add data

close data_file2 when done

delete data_file (original)

rename data_file2 to data_file


on startup the sw will be able to detect if a crash occurred and respond
appropriately. The code on startup should be pretty straight forward

By the way, the platform is java on linux (probably red hat)

Joseph

Jul 17 '05 #47

P: n/a


could you explain this a little more . thanks
Joseph
I have not read all the preceding emails but I was
just reading a java book last night and it says to
write the file to a temp file first then do a copy
as a single operation. If the crash occurs:
1. writing temp -> the old official file is still good
2. during the copy -> the temp is still good
you probably have to figure out 1 or 2 manually during
the crash recovery

And, if my temp file is corrupted, i wont be able to write to it.

However,
it's possible to detect corrupted files using java api fuctions. I'll be
able to detect any corrupted file and simply delete it.

I know i'm asking alot of questions which have pretty much been answered,
but I'd like to feel more sure about all this.

thanks

Joseph
Joseph wrote:
>
> Hi all
>
> I'm thankful to everyone for sharing their opinion. I read everybody's
> post
> and learned allot. It turns out that my algorithm will be simple,
> maybe something like this:
>
>
> Make a copy of existing data_file in the same directory
>
> operate on this new copy (data_file2) to add data
>
> close data_file2 when done
>
> delete data_file (original)
>
> rename data_file2 to data_file
>
>
>
>
> on startup the sw will be able to detect if a crash occurred and
> respond
> appropriately. The code on startup should be pretty straight forward
>
> By the way, the platform is java on linux (probably red hat)
>
> Joseph


Jul 17 '05 #48

P: n/a
that'll work....

- perry

Joseph wrote:
Hi
So just to confirm, if the OS crashes while doing a rename file or delete
operation, the files being renamed or deleted can't be corrupted right (ie
these operations are atomic) ? Just want to be 100 percent sure.

And, if my temp file is corrupted, i wont be able to write to it. However,
it's possible to detect corrupted files using java api fuctions. I'll be
able to detect any corrupted file and simply delete it.

I know i'm asking alot of questions which have pretty much been answered,
but I'd like to feel more sure about all this.

thanks

Joseph
Joseph wrote:

Hi all

I'm thankful to everyone for sharing their opinion. I read everybody's
post
and learned allot. It turns out that my algorithm will be simple, maybe
something like this:
Make a copy of existing data_file in the same directory

operate on this new copy (data_file2) to add data

close data_file2 when done

delete data_file (original)

rename data_file2 to data_file


on startup the sw will be able to detect if a crash occurred and respond
appropriately. The code on startup should be pretty straight forward

By the way, the platform is java on linux (probably red hat)

Joseph



Jul 17 '05 #49

This discussion thread is closed

Replies have been disabled for this discussion.