Issue 5614 - Accessing a directory with a busy component caused OO to appear to freeze / crash
Summary: Accessing a directory with a busy component caused OO to appear to freeze / c...
Alias: None
Product: General
Classification: Code
Component: ui (show other issues)
Version: OOo 1.0.0
Hardware: PC Linux, all
: P3 Trivial (vote)
Target Milestone: AOO Later
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2002-06-06 15:20 UTC by osavill
Modified: 2017-05-20 11:29 UTC (History)
1 user (show)

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


Note You need to log in before you can comment on or make changes to this issue.
Description osavill 2002-06-06 15:20:03 UTC
The scenario :

A par-port Zip drive on /mnt/Zip was busy deleting the entire contents of a 
250Mb Zip disc.

I wanted a document on /mnt/teams

I started OO, went to the File menu and selected Open. 
In the Open File dialog I navigated to /
I then double clicked on the "mnt" directory.


OO effectively froze. I could not get a reaction from either the dialog nor 
the main document frame. 

OO remained "frozen" until the Zip drive had stopped being accessed, then 
presented me with the contents of the "/mnt" directory.

There was no way for me to back up a level or to cancel the directory open 
since the dialog was unresponsive.

I only held on because I guessed what was happening, but to another user OO 
may well have appeared to have crashed. After all, I wasn't attempting to 
access /mnt/Zip itself.
Comment 1 thorsten.martens 2002-06-13 09:06:54 UTC
Problem was reported and discussed with the development section. The
file-open dialog tries to gain information about the directory/volumne
which is going to displayed in the file/folder window. But it can`t,
due to the fact that the folder/device is currently in use and
changing its content continiously. Development section and Program
Management will discuss, what can be done to avoid such problems. 
Comment 2 thorsten.martens 2003-02-13 15:05:08 UTC
Comment 3 thorsten.martens 2003-07-03 10:14:32 UTC
TM->BH: As talked to HRO this might be a wish for an enhancement.
Parallel-Port Operations are running exclusively and so opening the
file-open dialog and travelling to the busy device will lead soffice
to hang. A solution might be to let the file-open dialog run
asynchronus to avoid such problems (not only under Linux !). This
would be an enhancement. So please have a look, thanks !
Comment 4 bettina.haberer 2004-05-26 12:31:20 UTC
Hello Kai, this is also a timeout-problem like 7553. Some time ago the
asynchronus behaviour got trunced (don't now the reason). We need a decision
about. Could you please take over this issue; if you are not the right one,
please reassign it to the appropriate developer. Thank you.
Comment 5 ooo 2005-09-21 10:48:48 UTC
Comment 6 Marcus 2017-05-20 11:29:23 UTC
Reset assigne to the default "".