TM->FT: This one is a wish for an enhancement and therefore please have a look at it. Thanks !

Well, no technical asolution here! If you cut power our product has
_no_ chance to take any recovery action! The same goes for a craching
OS! It's only possible for apps that are more or less part of the OS ;o)

You are right Falco, but that's not what this issue is made for: IMHO
it's more like a feature request. I can imagine to change our autosave
feature in the way described in the issue. This is not a high-priority
issue, but a good point.

So setting it to "wontfix" without further discussion is too harsh.
AutoSave could behave the following way: every autocopy goes into the
"stor" folder (same as our "crash guard salvage" files), but the
"modified" flag is not cleared after autosave. If the document is
closed, the user will be prompted to save as usual. 
Alternatively the "modified" flag could be cleared on every autosave,
but the "autosave" state will be remembered. If the document is closed
in the state "autosaved", the user will be asked for saving. Then in
the state "not modified" saving the document only means copying the
last saved copy, in modified state of course the document is saved as
usual.

So I'd tend to reopen this issue as a feature enhancement request with
target > build 642.

Yes, please reconsider!

The point is this. If OOo (currently) is shut down without it having 
been able to save the document, all modifications (possibly hours of 
work) are simply lost. 
With the proposed feature, a copy of the document of at most [the 
autosave interval] old, will still be there on disk for OOo to 
recover. 

MS Word has this feature, and when Windows crashes on you with hours 
of work on an open document (as has happened to me on several 
occasions) then you sure appreciate it if your work has not simply 
vanished. 

For home use, I could live with the risk of occasionally doing the 
same work twice. In the office however, we cannot afford this! 
Therefore, this issue would be one argument in favour of sticking 
with MS Office instead of moving to OOo.

Please reopen!

Hi Folks. After a short discussion with Mathias in this matter I
concur that having an autosave that saves to a temporary file name
instead of overwriting the exisiting one seems sensible to me, too.
Mathias: I reopen this issue please put it on status "Later" thus we
might have this feature in a post version of 642 builds.
Furthermore we do need a _written_ concept/draft on this
implementation. Please contact me in this matter before stating
implementation.
Simon: Please take care what priorisation you use. This issue is
definenetaly no Prio 1! I downgraded it to appropiate prio 5.

Reassigned to Mathias Bauer

Hi Falko,
> Please take care what priorisation you use. This issue is
> definenetaly no Prio 1!
Sorry! I suppose I got carried away a bit there.

We will start with this after the work for accessibility etc. for the 
642 build.

User data loss is IMHO the most annoying thing, the showstopper nr 1 
for an application. You wont be able to avoid crashes in total, but 
you can and have to avoid user data loss with the proposed approach. 
I never have a problem with a crash as long as there is a reasonable 
amount of my data saved.
So please reconsider again to give this feature a higher (I would say 
top) priority, maybe even before fixing crash bugs.
To the statement of simon brouwer "OpenOffice has a recovery 
mechanism": yesterday I had a crash of OO and nothing was saved to be 
recovered later, so I don't see this mechanism. Anyway, if this 
mechansim is triggered by a crash, that means any procedure is called 
from this "event", than this is a much weaker and less robust 
approach than the proposed.

*** Issue 6007 has been marked as a duplicate of this issue. ***

I'm very glad this has been brought up as it is a very good point and
something I also ran into. The additional factor of this is that since
currently the Autosave feature saves to the current file rather than a
temp file, if the user has not yet saved the document at all, no
autosave will occur. In other words, if I just start a new document
via the quickstarter, then no autosave information gets saved until
the user actually manually names & saves the document. If autosave is
turned on, the user is given a save window that automatically pops up
which I understand, however, this can be annoying and would be
unnecessary if the autosave was saving into a temp file instead.

One additional point is that with the current functionality, backups
(if they are turned on) are not updated during autosaves, but only
during manual saves.

@Mikhail:
First we will implement the new "auto backup" feature as soon as a
specification is available

.

.

This is the way "autosave" works in WordPerfect: when you are editing 
a document, regardless of whether it's a new one or an opened one, 
WordPerfect stores a temporary copy of what you're editing in a 
particular folder. If the last WordPerfect editing session doesn't 
terminate correctly, any open unsaved files in WP will leave these 
temporary working copies "around" (i.e. in the temporary backup 
folder). Next time you start WP, it will detect these temps and ask 
you what do you want to do:

1. discard them
2. open them
2. save them

I would like autosave to be implemented in a similar way in OOo, with 
one improvement: the temp files should record the originating document 
filename+path (if any): one of the problem with the WP method is that 
unless you know what you were editing, you might have troubles 
resaving in the correct place.

Note that the autosave format needs not have anything to do with the 
official save format: speed has the highset importance when it comes 
to temp autosaving (since you don't want the GUI to 'pause' for 10 to 
30 seconds while autosaving!), so something similar to a serialization 
of the internal mem structures might be a good idea, rather than, say, 
the OOo fileformat of the particular app.

Hello,
I would like to add that this is an important issue.  I'm stunned that OO lacks
this fundamental feature which is present in seemingly every interactive
wordprocessor since vi. 

I note that there is presumably an easy quick solution that fixes the lost work
aspect problem.  I think the discussion regarding this problem fails to note
that a major aspect of the problem is that the user unexpectedly loses work.   
Thus, I suggest this could be "fixed" by displaying a dialog warning box saying
"no backup protection - see Saving Documents Automatically" if a file is opened
without autosave enabled.  That warning box would have the option to "not see
this warning again".

If OO did the above then the remaining issue is whether autosave and "always
create a backup copy" are good enough or whether they need to be enhanced.  The
trouble with the way backup copy and autosave are currently implemented is that 
the backup copy gets overwritten without an explicit user command and the user
might want to go back to the original and find it isn't there anymore.  And so
work is lost because now the original file has to be recreated.

I think autosave would be much better if it had an option to autosave to a
"draft" directory and overwrote the original file only via File->Save.

In conclusion, if OO gave a warning when a file was opened without autosave
enabled and allowed autosaving to a "draft" directory then I think the issue of
losing work would be solved.

MAV->AS: You are implementing the recovery feature, so I send this bug to you.

I will implement it in the following way:
- AutoSave save its documents into a special backup folder everytimes
(so the original files isnt touched any longer)
- Further it detects the state of this folder on every office startup. If there
exists files - they will be asked to be recovered.
- The user will get: the original file on its original location ... and most(!)
of the changes on that document as recovered AutoSave copy.
Note: Because AutoSave does not track ALL changes (because it is started every
"n"-minutes) there can be SOME missing data. But most of the work can be
restored from the backup copy.

New implementation started ...

The new AutoSave feature will save your documents every "n" minutes. Further
these files will be restored automaticly if you start the office again. This
mechanism will work on a system crash too. Because these AutoSave informations
will be available there too.

Of course you will loose your changes between the last AutoSave action and the
crash. E.g. if you cut the power cable, we cant do anything!

I am concerned about the "Further these files will be restored automaticly if
you start the office again" comment regarding the design of the fix.  That
suggests the original could be overwritten even if the user had no intent on
saving the work in progress file.  That could be a disaster far worse than the
original problem.

The comment should be that files with changes are stored into a backup folder so
if OO program doesn't terminate properly then the next time OO is run then the
work in progress files are detected and OO then has some of dialogue with the
user to determine what to do next.  It would be good to describe how that part
is supposed to work as part of this bug report/fix.

Also, I am not sure why this feature needs any sort of special testing.  If it
uses the same routines for loading and saving files as File->Save/Load then
program failures during those writes/loads are probably more important than when
being used by autosave.  The more important part of the testing is to make sure
it isn't too easy for the user to delete either their original or the backup
when the user was only trying to examine files to determine which one was the
copy to keep.

Reopened for sending bug back to the QA

Reassign issue to JA

Restore Fixed state

JA: verified in cws recovery04. Created follow-up issue i37402 which has to be
fixed within Beta timeframe on a different CWS

JA: integrated into master since m64

Autosave and Autorecovery in my experience are two very differnt features,
implemented in differnet ways. True that they may share some very common
components, but Autosave is equivalent to doing file-->save every n minutes,
whereas Autorecovery only creates a temporary copy of the changes. This temp
copy is deleted if the application is shut down correctly and any changes lost
if the user has not forced a conventional save.

I originally started using OOo, because MS had abandoned Autosave and put in
autorevery in its place. I was losing vast quantities of work, because I was
relying on an autosave which did not exist! When I closed the application down
properly, all the temporary autorecovey files were erased and my hard work edits
(which had not been saved or auto-saved) were lost. This appears to have been a
common complaint as MS were forced to issue a VB add-on to each of its office
products, reimplementing the autosave feature. Although the VB add-on works, it
is pretty pathetic as it does not utilise a common UI over each product in the
office family. OOo 1.x was streets ahead in this respect....

I think it is a good thing to include an auotrecovery feature in OOo, but please
please please do not ditch the Auto save feature - keep both operational but
distinct from each other. I bring this up, because auto save has vanished from
OOO 1.9.65. I strongly suggest that it is reimplemented before v2 hits the world.

Regards,
John

@lippj:

If you close the application normally, it asks if you want to save the changes
doesn't it? If you choose "Save" then the document is saved and your "hard work
edits" are not lost. 

Or do you mean that if you choose "Reject" on closing the application, OOo
should save the file anyway (under another name) in case you change your mind
about it later?

If that is what you mean, I suggest that you file another (enhancement) issue,
because that would be something else than either AutoSave or AutoRecovery.

JA: please read
http://specs.openoffice.org/appwide/recovery/Autorecovery.sxw
and
http://specs.openoffice.org/appwide/errorreporter/error_report_2_0_ui_specification.sxw
to get an idea how thinks changed within current 1.9.x builds