Bug 652472

Additional comment.

The problem seems to be related to the oo - quickstarter.

Using the quick starter from the gnome panel did not change the situation.

Removing the quick starter and opening a new writer instance had the following result: The quick starter got re-installed in gnome panel and the writer had still the same slow motion problem.

Removing the quick starter and opening a new writer instance a second time:
Quick starter did not get re-installed in gnome panel, typing speed in writer is back to normal.

I don't see anything like this. Do you use Metacity or Compiz (or Gnome Shell)? Which theme do you use? What is your locale? (If you're not sure, run

gconftool-2 -g /desktop/gnome/session/required_components/windowmanager
gconftool-2 -g /desktop/gnome/interface/gtk_theme
locale

to get the answers.) Which graphic driver do you use?

Hi David - 

One Q: 
How could I re-create the OO-quickstarter. 
I hope I could dig a bit deeper then. 

And the info ...

[joy@joyt41 ~]$ gconftool-2 -g /desktop/gnome/session/required_components/windowmanager
metacity

[joy@joyt41 ~]$ gconftool-2 -g /desktop/gnome/interface/gtk_theme
Clearlooks

[joy@joyt41 ~]$ locale
LANG=de_DE.utf8
LC_CTYPE="de_DE.utf8"
LC_NUMERIC="de_DE.utf8"
LC_TIME="de_DE.utf8"
LC_COLLATE="de_DE.utf8"
LC_MONETARY="de_DE.utf8"
LC_MESSAGES="de_DE.utf8"
LC_PAPER="de_DE.utf8"
LC_NAME="de_DE.utf8"
LC_ADDRESS="de_DE.utf8"
LC_TELEPHONE="de_DE.utf8"
LC_MEASUREMENT="de_DE.utf8"
LC_IDENTIFICATION="de_DE.utf8"
LC_ALL=

[root@joyt41 ~]# lspci -v |head -16
00:00.0 Host bridge: Intel Corporation 82855PM Processor to I/O Controller (rev 03)
	Subsystem: IBM Thinkpad T40 series
	Flags: bus master, fast devsel, latency 0
	Memory at d0000000 (32-bit, prefetchable) [size=256M]
	Capabilities: [e4] Vendor Specific Information: Len=04 <?>
	Capabilities: [a0] AGP version 2.0
	Kernel driver in use: agpgart-intel

00:01.0 PCI bridge: Intel Corporation 82855PM Processor to AGP Controller (rev 03) (prog-if 00 [Normal decode])
	Flags: bus master, 66MHz, fast devsel, latency 96
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
	I/O behind bridge: 00003000-00003fff
	Memory behind bridge: c0100000-c01fffff
	Prefetchable memory behind bridge: e0000000-e7ffffff

(In reply to comment #3)
> One Q: 
> How could I re-create the OO-quickstarter. 
> I hope I could dig a bit deeper then. 

Tools->Options->OpenOffice.org->Memory, check Enable systray Quickstarter

The check is already enabled. 
Though I do not have the quick starter showing up in the panel.

I have to 
   Tools->Options->OpenOffice.org->Memory, uncheck Enable systray Quickstarter
   exit openoffice
   start openoffice
   Tools->Options->OpenOffice.org->Memory, check Enable systray Quickstarter
   This  will display the quick starter.
    
   After exiting writer and exiting the quick starter I got a crash
   (bug  652695)
   
   I'll try to follow all the steps, which supposedly led to the slow motion, as
   close as possible.

Hello David,

I could not verify the slow motion the way I originally experienced it.
However have discovered the underlying root cause which likely
did exhibit such a strange sideeffect.

I was editing a document (7.2MB) located on a remote host.
The remote directory was mapped via sshfs. 
When changing sessions (GNOME -> KDE -> GNOME)
the sshfs connection got dropped (obviously :-).

I have repeatedly tested the following steps:
(The swith KDE/GNOME is not importand) 

  - Map the remote directory to a local path via sshfs. 
  - Open the remote document and change it - no save
  - Reboot, to make sure there is no unknown state. 

  - login (gnome)
  - oo writer Document Recovery is being displayed.
    It has to be noted that two instances of the same document are being listed.
  - Start WLAN
  - sshfs to remote server
  - Quick start icon shows up in gnome panel
  - Click start recovery
  - Change document - no save
  - Reboot 

  - login (gnome)
  - oo writer Document recovery is being displayed.
    again two instances of the same document are being listed.
  - Click start recovery (NO sshfs).
  - Document recovered and displayed (once).
  - sshs fails  .. correct
    read connection reset by peer (no WLAN) 
  - start WLAN
  - sshfs fails - not expected
    fuse mount point not empty !!!!
    The problem:
    oo writer created a path under the local directory with the
    path structure from the remote path 
    (+ lock file + Document if saved). 
              
    This hidden 'feature' should not be exercised w/o a warning that 
    the original directory is missing for proper recovery. 
    If the recovered document is being stored under the added local directory 
    then the original document will be inacessible. 
    Further, the 'local duplication' is not obvious.
    Data might be lost if at a later time the user discovers that the 
    remote directory content is not available and 
    the user will remove the local duplicate.

  - The added path has to be removed manually. 
  - sshfs connection - OK
  - The dokument can be saved in the reote path.
    At this point oo response time is about 5sec when redisplaying 
    the window and 13sec or more to save the document 
    (the "slow motion" then is due to the shhfs connection.)

So, to summarize, if one opens a file on a mounted dir, makes some modifications, and don't save them, then on the next session if that dir is not mounted, OOo will write the file back under the unmounted dir of the mount point instead.

Yes - that's the result.

Hi,

Part 1 got fixed: 
The recovery step will not write the file back under the unmounted dir of the mount point.

Part 2:
If the remote dir got mounted the recovery procedure works as expected:
- Edit remote file via sshfs - no save 
- reboot
- start oo, recover dialog popup
- start wlan, mount remoted  dir
- run recover, OK 

 
Part 3, where problems remain:
Part 3a:
- Edit remote file via sshfs - no save 
- reboot
- start oo, recover dialog popup
- run recover, recover error  - that's OK 
- stop oo
- start wlan, mount remoted  dir
- start oo, recover dialog popup
- run recover, recover error  - NOT OK:
  The file name to recover is being displayed but the file name to recover is
  not being related to the sshfs dir (which is available at this point).
Part 3b:
- Edit remote file (same file as before) via sshfs - no save 
- reboot
- start oo, recover dialog popup
  The Recover dialog has three entries, identical filenames. 
- start wlan, mount remoted  dir
- run recover of most recent (first) file entry - OK
Part 3c:
- The file to recover from Step 3a (same file as in 3b) is still being displayed
  in a separate entry within the recover dialog.
- The immediate recovery step for the remaining entry for the same file name
  fails.
  No recovery is done. 
  The recovery has to be cancelled to clear the recovery dialog. 
  There is no obvious way to recover the listed files.

I'm tempted to say, "well don't do that then". Its very unclear what OOo should do, or should be capable of doing, under these circumstances.

Hi, 

one might say so.....

Now a slight variation on the theme:

My friend has a dual Ubuntu / win installation (laptop). 

From OO he got a
...
'Document locked by unknown user.'
....

He also got the recovery prompt any time he started ooffice.

The problem started after a web page froze his system.
He did a Power off/on. Started OO and did recover the docs he was working on. 
After that the access to 'some' (act. all) other docs got blocked.

I finaly discovered that the mount point 
/media/4C70-391C_    (note the  '_')
and the dir 
/media/4C70-391C existed.

The scenario is quite similar to above described nfs-mount scenario.
Except the disk in this case is a local NTFS and it gets mounted 
when accessed via Nautilus.
 
Scenario after crash reboot:
The recovery dir got created as /media/4C70-391C
The next mount was done under /media/4C70-391C_    (note the  '_') - BINGO

So - well -  can't tell my fried "don't do it :-)" 

Fix: 
unmout  /media/4C70-391C_ 
rmdir /media/4C70-391C
The next mount was OK under /media/4C70-391C

OO must not silently create a dir if it does not exist any more
but still is in the document path:

Warning:
The path (NAME) of your document does not exist any more. 
Please make sure, that the proper remote, external, or internal disk 
is being connected and/or mounted.
Then retry recovery.
Retry  |  Store in diffrent location  |  Cancel   | Discard

caolanm->sbergman: can you have a look at this one, other scenarios could be editing a document on a usb key, crash, remove key, restart Libo and end up with the recovered document being created in a /media/mount-something dir. 

Maybe it's best to check if the dir to auto-recover into exists, and not create them if they don't, and use some other generic dir for recovery

What I take from the various comments here is the following:  OOo (3.3?), when starting up detecting it should recover a document in path P, and that path does no longer exist, recreates that path.

I tried to reproduce this with the following scenario:

$ mkdir ~/test1
$ soffice -writer # create and save some ~/test1/foo.odt; quit
$ soffice ~/test1/foo.odt & # type some more; do not quit
$ ps ... | grep soffice.bin # find the soffice.bin pid
$ kill -9 ... # kill the soffice.bin
$ mv ~/test1 ~/test2
$ soffice

...comes up, asks to recover ~/test1/foo.odt, when instructing it to do so fails with an error that ~/test1/foo.odt is not accessible, and does not create any new ~/test1 directory.

This behavior I consistently observed across a range of OOo/LO versions, from OOo 3.2 to LO 3.4.5 to LO master towards 3.6 (in latter versions, multiple error messages about the missing foo.odt show up, but in no case was the missing directory recreated).

What am I missing?

I think we got ourselves into a tangle of confusion here. We need a super-simple step-by-step to reproduce this locally. Feel free to reopen if you still have the problem and can give us a step-by-step.