@Rjwilmsi 07:01, 6 May 2014 (UTC) wrote:

Makyen: Have you tried right clicking in the edit box and choosing Replace text with last edit, documented at Wikipedia:AutoWikiBrowser/User manual#Edit box context menu?

Makyen (talk) 00:30, 7 May 2014 (UTC) wrote:

No. While I did look for such a feature, I completely missed it in the context menu. I had hoped something would exist given the existence of autosave.txt, but failed to find it. Sorry about that.

However, I did, at the times, check the actual contents of autosave.txt. That file contained either a total of 3 bytes (Unicode byte order mark), or a copy of the unedited article, not the previously edited contents. The next time this happens I will try the function available from the context menu to verify that there is an actual problem here rather than just a failure on my part to use the features already available.

If the "Replace text with last edit" function fills the article content from the current contents of autosave.txt it will not recover the text as edited as the edited contents were not there. If it fills from a version of the text internal to AWB, then this is probably user error and not a bug. Although, it would be nice if the autosave.txt file, or a temporary copy of it, continued to have valid contents from the previous edit through the beginning of hand edits for the next page.

Hmmm... The Unicode byte order mark version – I saved, via copy, a couple of versions of autosave.txt – may be from one of the times AWB went into an infinite restarting countdown loop (a bug I have not yet filed; seen at least twice; requires killing and restarting AWB).

@Rjwilmsi 07:26, 7 May 2014 (UTC) wrote:

Autosave.txt and Replace text with last edit are unrelated.

Makyen (talk) 10:22, 10 May 2014 (UTC) wrote:

Thank you for the information.

I confirm the primarily issue as my failure to RTFM. The use of the "Replace text with last edit" appears to solve the majority, but not all, of the times this is an issue. [NOTE: The single failure of saving .. restarting .. re-edit is rare. It has only happened twice since the above post pointing me at the manual, but in both cases "Replace text with last edit" has restored the edited text.]

However, there is a rarer situation for which it would be nice to not have autosave.txt overwritten prior to hand editing the next article (or at least until the article is confirmed as saved). On a couple/few occasions AWB has gotten into infinite, or semi-infinite loops. The first reason this has happened has been due to unknown causes where AWB will repeatedly do the "Restarting in XX" countdown and apparently never get out of it. I have always killed AWB after it has run through that process several or a few times. AWB might get out of it on its own eventually, but it does not do so in the time I have let it run. In those situations, the edit is not saved and the autosave.txt file does not contain the contents of the edit. it would be helpful if that file was not overwritten until the next article is being edited rather then at, or shortly after, the save button is clicked.

However, this is a much more rare occurrence than just failing to save and bringing up the same article again (say like 1 in 10??).

On the other hand, my assumption from the existence of an autosave.txt file is that it is supposed to be the last fallback to obtain a copy of the edits in the case of an AWB crash, system crash, or other such failure. Assuming that is the case, it should not be overwritten at least until the edit is confirmed as saved.

@Rjwilmsi 08:13, 11 May 2014 (UTC) wrote:

Makyen: The autosave is based on a timer only. There is also a right click option in the edit box to save the entire contents to a text file at any point you like. What are you expecting in addition? A third option whereby AWB automatically saves the edit box text each time the user press Save, so that text file remains until the user presses Save again?

Makyen (talk) 00:28, 13 May 2014 (UTC) wrote:

@Rjwilmsi: As I understand the function of a file like autosave.txt is that it is a last ditch backup of the edited contents of the page. Ultimately, what I was reporting was that on a few occasions I did not find the hoped-for contents when I went to the autosave.txt file to find a backup copy of text which I had hand edited. This was on pages for which I had clicked the save button but not had the page actually save. The "Replace text with last edit" context menu function solves this issue in the majority of cases, but not all. What I was suggesting as a way to make it such that the contents of the possibly lost edit be available in as many failure modes as possible is that the autosave.txt file not be overwritten until the user manually edits the next page. Specifically, the file was blanked on at least one occasion (I don't specifically remember about others). On that occasion the entire contents of the file was a Unicode byte order mark. This implied to me that the file was overwritten at some point when AWB did not actually have any data in the buffer. This would be consistent with the file being written with the contents of a buffer, upon callback from a timer without checking to see if the contents of the buffer were valid.

Making a change would cause the logic for saving the buffer to autosave.txt to be somewhat more complex than only on a timer. In the callback from the timer, prior to saving, it would need to check to see if the current buffer was valid or had been manually changed. The manually changed part might make this more complicated than needed.

Having a third backup method/option (make additional backup upon clicking save kept until clicking save on the next page) is a valid solution to the desired function of having a backup in case of failures and would solve the issue I reported. It would also keep the backup available to the user for a longer time. Given that it is just a call to save the text in a file each time the save button is clicked it might be easier to implement than checking for a manual edit in the current auto-save timer function.

Basically, what I would like is a way to recover manually edited data when the save fails and AWB never makes it to the point where "Replace text with last edit" can be used. I had assumed the autosave.txt file would fill this need, but found that it did not when I tried to find lost edits.

It appears I am not communicating well. Perhaps if I describe the logic I am attempting to communicate: Suggested logic (based on assumptions from your description above):

main program: buffer valid flag set when data from a page is ready ("Ready to save") to be edited by the user. Flag cleared when "Processing page" (i.e. during re-parse). Function to save autosave.txt file called upon user clicking save, then buffer valid flag cleared.
autosave.txt timer callback: save if buffer valid flag is set. Do nothing if buffer valid flag is cleared.

I believe that would solve the issue which I had of not finding data in the autosave.txt file when the problem/crash/hang occurred between clicking save and being presented with a page to edit ("Ready to save").