Issue 107904 - Backup for the document recovery is not updated.
Summary: Backup for the document recovery is not updated.
Status: CLOSED DUPLICATE of issue 108012
Alias: None
Product: General
Classification: Code
Component: ui (show other issues)
Version: OOO320m8
Hardware: PC All
: P2 Trivial (vote)
Target Milestone: OOo 3.2
Assignee: thorsten.martens
QA Contact: issues@framework
URL:
Keywords: oooqa, regression, release_blocker
: 108018 (view as issue list)
Depends on:
Blocks: 99999
  Show dependency tree
 
Reported: 2009-12-26 23:36 UTC by jmaguro
Modified: 2017-05-20 10:01 UTC (History)
9 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
screenshots showing empty folder and settings (108.35 KB, application/pdf)
2009-12-28 15:14 UTC, Rainer Bielefeld
no flags Details
Scenario 1 with a saved document (373.78 KB, application/x-compressed)
2009-12-30 18:15 UTC, majukr05
no flags Details
Scenario 2 with an unsaved document (223.94 KB, application/x-compressed)
2009-12-30 18:16 UTC, majukr05
no flags Details
screenshot of backup folder (can not upload 0B file) (154.97 KB, image/png)
2010-01-01 12:29 UTC, r4zoli
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description jmaguro 2009-12-26 23:36:34 UTC
Environment:UbuntuLinux9.10

1,Open new document(writer,Calc,Impress,Other..).
2,Edit document.
3,Wait 15 minits(waiting automatic backup).
4,Shutdown OOo by kill command.
5,Launch OOo.
6,OOo start the"Document Recovery" ,And Recovered Document is open.
7,However, edited content doesn't remain.
Comment 1 Rainer Bielefeld 2009-12-28 15:11:41 UTC
Reproducible with "Ooo 3.2.0 RC1 WIN XP DE-multilingual version German UI
activated [OOo320m8 (Build 9472)]"!
Backup folder is completely empty, Recovery will be done, but it will recover
the latest manually saved version, not the one from max. 15 minutes ago (due to
m settings).
Comment 2 Rainer Bielefeld 2009-12-28 15:14:07 UTC
Created attachment 66867 [details]
screenshots showing empty folder and settings
Comment 3 uwe.luebbers 2009-12-29 12:18:06 UTC
set target
Comment 4 wope 2009-12-29 18:19:04 UTC
Also for SuSE 11.2 OOo3.2rc1, there is no recovery
Comment 5 majukr05 2009-12-30 18:12:55 UTC
OOo 3.2.0 RC1 OOO320_m8 (update 3.1.1) on WinXP:

AutoRecovery is working fine for me (only Writer tested).

See the attached case scenarios:
Options > Load/Save > General
[✓] Save AutoRecovery information every 10 minutes

- Scenario 1 (ar_test1.zip) with a saved document
- Scenario 2 (ar_test2.zip) with an unsaved document.

The attached *.odt files are the recovered files.
Comment 6 majukr05 2009-12-30 18:15:29 UTC
Created attachment 66921 [details]
Scenario 1 with a saved document
Comment 7 majukr05 2009-12-30 18:16:40 UTC
Created attachment 66922 [details]
Scenario 2 with an unsaved document
Comment 8 majukr05 2009-12-30 18:18:52 UTC
.
Comment 9 r4zoli 2010-01-01 12:20:00 UTC
I tested (partiaqlly) on opensuse 10.3.
And found the next:
When you allow to create backup copy of documents, and set backup time to 2
minutes, it creates autosave files (for example filename.odt_0.odt) with 0B
size. It can cause that recovery can not give any results. 
And it works very spontaneously sometimes works after 2 minutes, sometimes not.
Creates multiple _x.odt files where x is 0,1,2,3,4,5 (filename.odt_5.odt is the
latest), all files 0B size. 
I tested with a copy of file ~1MB size
(http://www.pitonyak.org/database/AndrewBase.odt), opened it and still open 3
hours, added some spaces to text,  after ten minute, stayed open during lunch
(~1 Hour) added more spaces.
I made manual saving, it created a normal ~1MB backup copy in backup folder.
I attach one of 0B size file from backup folder.

Comment 10 r4zoli 2010-01-01 12:29:15 UTC
Created attachment 66931 [details]
screenshot of  backup folder (can not upload 0B file)
Comment 11 r4zoli 2010-01-01 13:30:55 UTC
*** Issue 108018 has been marked as a duplicate of this issue. ***
Comment 12 thorsten.martens 2010-01-04 12:38:21 UTC
TM->MAV: Problem is reproducible in a 320m8 build and seems to be OK in a 320m7
build.
Comment 13 thorsten.martens 2010-01-05 14:31:03 UTC
reassigned
Comment 14 carsten.driesner 2010-01-05 14:32:27 UTC
cd: Seems to be a duplicate to issue 108012.

*** This issue has been marked as a duplicate of 108012 ***
Comment 15 thorsten.martens 2010-01-07 11:10:15 UTC
Checked and verified in cws fwk134 -> OK !