thoughts on file saving safety

[CADTenchy]

My app will be saving a growing text file to hard disk regularly.
This could be every 10 or 20 minutes or so, up to a maximum frequency of about once a minute. It will be used anywhere between 4hrs and 24hrs continuously when in use, but that might be once a week probably at most.

My data is held in a stringlist and I'm using

stringlist.SaveToFile('filename.txt');

to do the saving.

Plan A was just to use the line above each time a save is required.

Plan B is to do this at each save:

if exists filename.bak then delete filename.bak;
rename filename.txt to filename.bak;
stringlist.SaveToFile('filename.txt');

Which would you think has best integrity, all in all, given the save frequency?


Steve (Delphi 2007 & XP)

 

[roo0047]

Daddy - Don't feel too bad, I thought my suggestion was misinterpreted as well, which intentionally did NOT include the actual WriteToLogFile() routine code block.

Looking at the OP's original query, although he specified his data frequency, missing is the potential data size.
[ol]
[li]Is it necessary to create a file backup for every write-to-disk? No.[/li]
[li]Is it advisable to create a file backup at program start? Probably yes.
my demo, btw[/li]
[li]Should the write-to-disk include a try/except to handle ANY disk-write-error? Absolutely yes.[/li]
[li]Is there any danger in calling a final file-close in the OnFormDestroy event? No, not any more dangerous than putting it in the finalization block of a unit.[/li]
[/ol]

I typically use StringLists as temporary storage within a single routine, where it's created, used and freed. Each List.Add() is sequential. I prefer TMemo to proved the user with visual progress information. For data, it's best to write to disk with open (append), write, close, which is sequential. I often combine Memo.lines.add() within the same routine where I write to disk if that's what I'm doing. Continually using List.SaveToFile() is not sequential, although the result may appear to be. I think that's what so many were trying to tell the Op.

As pointed out, if the file is left open, your write-to-disk should include a flush-to-disk if someone pulling the plug would be catastrophic. You have to consider "Are you doing a destructive read?" or can the output be recreated by running again with the same input? If partial data has no value then why bother saving until the end?

This thread appears to have taken a twist when I brought up log-files. My apology.

Most coders have their own way of saving data and re-use their own code. There's really no wrong answer if yours works for you. You can Google all day, and all you'll get is how someone else does theirs. You need to create your own and let it evolve to suit YOUR needs and style.

"Garbage in, garbage out".
Roo

 

[harebrain]

Well, then, we're all even and misunderstood.

I didn't (and don't) think there's anything safer than logging the data IMMEDIATELY, as it's acquired. No intermediate holding tanks that need periodic inspection before flushing to a device. Acquire it, write it, repeat until done.

For the OP's requirements (1000 records of 100 characters over a time period of up to 24 hours -- less than one write per minute) this is adequate, safe, and simple. FOR HIM (i.e. without an existing, tested, proven solution) anything more elaborate would just introduce potential points of failure, which is precisely what he doesn't need.

 

[sggaunt]

Well, then, we're all even and misunderstood.

Don't worry about it this sort of this happens all the time in textual forums (as opposed to real world discussions).

Did Cadtenchy ever explain why he didnt use an 'append to file' strategy to do this sort of thing, I probably missed it?



Steve: N.M.N.F.
If something is popular, it must be wrong: Mark Twain

 

[CADTenchy]

I didn't explain why I wasn't using an append to file strategy, I can though.
The answer is simply that as I was using a stringlist to store the data during run time for access to it, I used the ready to roll easy option of the SaveToFile and LoadFromFile methods of stringlist.

I haven't implemented the changes I plan to my app, which is to do the line by line saves as serial appends, but I shall do when I get back to it.

sggaunt is right though, textual 'talk' can often be mis-read, seen it time and time again in usenet, email and cell text messages.
In programming, I'd say no-one is right, no-one is wrong.
But different points of view, and methods, are essential!

I find there's methods and ideas to be drawn from from every post, and welcome all.

Steve (Delphi 2007 & XP)

 

[Glenn9999]

Is there any reason why you can't keep more than one backup?

(nothing necessarily related to the quote)

I ended up writing something (as I openly "thought" about in another post) that makes multiple backups of data files that can be called as an Assign statement, and will also allow easy read access to a backup by specifying the backup number. I can post it, when done, if interested.

But some questions/thoughts, if anyone is willing to offer:

Right now, I contained all the logic within the assign, but I'm thinking too that it might be more fault-tolerant to make a reset/rewrite/append with proper logic in it to make sure a backup isn't written over. I'm sure much would depend on the care of the programmer writing it (there's always the possibility of straight rewrite of a backup, anyway, unless there's a nice way under XP/Vista to create the file as to stop it). Much of the thought behind this is just trying to enforce some rules so the backups are protected, and there is a minimum of programmer confusion. So, any ideas on what would be best to approach this?

----------
Measurement is not management.

 

[harebrain]

I ended up writing something (as I openly "thought" about in another post) that makes multiple backups of data files that can be called as an Assign statement, (etc.)

Doesn't this warrant a new thread, Glenn?

(It's a rhetorical question. The answer is, "Of course it does.")

 

[Glenn9999]

Doesn't this warrant a new thread, Glenn?

(It's a rhetorical question. The answer is, "Of course it does.")

Does it relate to this problem at hand? The original one in post #1? Sure. That's what prompted me to write it in the first place. That's why it was posted here. Does it matter if the last post was placed in this related thread or a new one? Truthfully, in the end, not very much.

I could go ahead and post a new thread, but would it be worthwhile? Perhaps not.

----------
Measurement is not management.