Re: How can I do a 100% bullet proof 'Save'?

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: Simon (sorde_at_gotadsl.co.uk)
Date: 09/24/04 

Date: Fri, 24 Sep 2004 10:16:56 +0100

Actually I think your way is better. Suppose we assume that the chance of
the save process itself failing is one in a million and the chance of either
delete file or rename failing is one in a billion (near enough guesses for
my purposes), then the chance of my approach failing (i.e. producing the
'bad result' of a wrongly named original file after a failed save, on any
given occasion) is approximately one in a billion. The chance of yours
failing is much harder to calculate and my probability isn't up to it right
now, but its very roughly in the region of "1/m x (2/b)" (i.e. one in a
million x 2 in a billion). Which implies that your approach is
significantly better.

Simon

"Simon" <sorde@gotadsl.co.uk> wrote in message
news:4153e126$0$52238$65c69314@mercury.nildram.net...
> Norm (& others)
>
> I think your suggestion sounds not bad. It's still not 100% bulletproof
> (i.e. failure could still lead to a situation where the old file is not
> left unchanged); but it may be better than what I'm doing now. If so,
> only v. slightly though.
>
> There are pluses and minuses of the 2 approaches. With both your way and
> mine, it can never happen that the save fails and the original file is
> deleted. But, again with both, it can happen that after a failed save,
> the original file is left with the wrong name.
>
> Your approach has the following advantage over mine: With mine, the bad
> result (wrongly named original file) can arise as a result of a single
> point of failure - namely the final rename. With yours, the user will
> only be left with a wrongly named original file if at least 2 things fail:
> (a) the actual save process (writing to the file) must fail, and (b)
> either the subsequent attempt to delete the file you've been writing to,
> or the attempt to rename the original file back to its original file name,
> must also fail.
>
> The advantage of your approach over mine is therefore that 2 things have
> to go wrong in the same operation for the bad result (wrongly named
> original file) to occur. And as there is no reason to expect that these
> failures would be in any way related to one another, that would be
> exceptionally bad luck.
>
> However, the disadvantage of your approach is that there is slightly more
> to go wrong. On my approach, the bad result can only arise if the final
> rename fails (which is exactly what happened). On your approach, if
> either the delete file fails, or the final rename, the bad result will
> arise.
>
> So, its pretty finely balanced. I'm not sure which is better really.
>
> I remain convinced that there ought to be a 100% bulletproof solution to
> this one. If the Win32 API doesn't offer a solution, it should. Why not?
> All you need is for the file system to provide a mechanism for renaming 2
> files simultaneously (or something similar) as part of a single
> transaction. What do you think MS Office products do?
>
> Simon
>
>
> "Norm Dresner" <ndrez@att.net> wrote in message
> news:SQL4d.421681$OB3.134852@bgtnsc05-news.ops.worldnet.att.net...
>> "Getty" <eddy_ruslim@telkom.net> wrote in message
>> news:82657572.0409231109.35a32698@posting.google.com...
>>> "Simon" <sorde@gotadsl.co.uk> wrote in message
>> news:<4152d4cc$0$10791$65c69314@mercury.nildram.net>...
>>> > I have an app that saves to a file. I want my save to be a 100%
>>> > safe -
>> i.e.
>>> > if the save fails for any reason, the file on disk is left completely
>>> > unchanged. So this is what I do:
>>> >
>>> > I get Windows to generate a temporary file name for me in the
>> destination
>>> > folder and I save to that file.
>>> > If the save succeeds, I delete the old file and rename my saved file
>>> > to
>> give
>>> > it the old name.
>>> >
>>> > If anything fails at any point, I leave the old file alone and tell
>>> > the
>> user
>>> > that there's a problem.
>>> >
>>> > That has worked very well up to now, but I have just had a user who
>>> > got
>> an
>>> > error message which could only happen if (a) the initial save had
>> succeeded,
>>> > (b) the old file had been successfully deleted and (c) the attempt to
>> rename
>>> > the saved file (with the temp name) to use the old name, had failed.
>>> >
>>> > I have no idea how that could have failed, but apparently it did. In
>> fact
>>> > it wasn't disastorous because my program left the saved file where it
>> was
>>> > with its temp name, and put out a detailed error message explaining
>>> > what
>> had
>>> > happened, and advising the user to manually rename this file herself-
>> which
>>> > she did without problems. But I would like to be sure that nothing
>>> > like
>>> > that could ever happen again. So does anyone have any suggestions -
>> either:
>>> > how this could have happened (and how I could have prevented it)? Or
>>> > perhaps suggestions of an alternative approach that would be
>>> > absolutely
>>> > bulletproof. It occurred to me that what I could really do with is a
>>> > "SwapNames" function which would swap the 2 file names as an atomic
>>> > transaction, and be incapable of failing with the job partly done.
>>> > But
>> I
>>> > don't know of any such feature in the Win32 API. Anyway, all
>> suggestions
>>> > welcome.
>>> >
>>> > Simon
>>>
>>>
>>> What about the other way around! copy a backup file then open the file
>>> for direct edit?
>>> hope that help or at least glow some spark! :-)
>>> ddy Ruslim
>>> -----------
>>
>> Along the same lines:
>> 1. Rename the original file to whatever.BAK
>> 2. Write the new file.
>> 3. Delete the old file
>> If writing the new file fails, you can
>> a) try deleting it (if necessary) and renaming the original file to
>> its
>> original name
>> b) in any event, tell the user exactly what happened.
>> With this method, there's always an original file until the moment you
>> want
>> to get rid of it.
>>
>> Norm
>>
>
>

Relevant Pages

  • Re: How do I get a list of filenames with spaces on bash?
    ... To ensure that in the event of a failure the original file is unaffected. ... in that case, mv doesn't affect the file not even its inode, it ... affects the current directory, it's just a rename. ... A failing cp may leave an ...
    (comp.unix.shell)
  • Re: trouble with msconfig.exe
    ... The original file has been renamed to msconfig.old (I don't know the ... msconfig.exe directly from Windows installation CD-Rom (it's Windows XP ... I can't rename or delete msconfig.old. ... Be sure the machine is clean first: ...
    (microsoft.public.windowsxp.general)
  • Re: lots of _RBLDAxxxx after table rebuilt
    ... The rebuild utility does not rename the original file until the ... rename that rebuild does after it rebuilds the file. ... Just do like the rebuild utility would do and delete the original ...
    (comp.databases.btrieve)
  • Re: How can I do a 100% bullet proof Save?
    ... original file is left with the wrong name. ... of failure - namely the final rename. ... to rename the original file back to its original file name, ... fails. ...
    (microsoft.public.vc.mfc)
  • Re: STILL Unable to use YUM to update
    ... John Moore wrote: ... I tried to rename it but it won't rename. ... result from an editor renaming the original file as a backup when saving ... If that backup file contains anything ...
    (Fedora)