Apache OpenOffice (AOO) Bugzilla – Issue 21747
Directory lock until quickstarter closed
Last modified: 2010-11-28 18:20:51 UTC
If I open a file on a pendrive using OO.org I'm unable to unmount the device if I don't close the OO.org quickstarter utility. just a little bug but can be confusing for inexperienced users. Found on a PC with windows 2000 sp4 and OO.org 1.03 and 1.1 Regards Marco Berrettini
change from test. CMIIW
Hi, please note! If this defect is a real issue, please change the component, cause testproduct is only for testing. Otherwise close the issue. Thank you
component has been changed to framework, subcomponent code
should be the right subcomponent (I hope :))
TM->HRO: As talked about, please have a look. Thanks !
The Windows "Black box" System File Open Dialog sets the current working directory to the directory where the last file was openend from. That locks the directory and prevents the volume from unmounting. hro@tra: After system file open dialog is closed remember the directory, set the current working directory to somewhere uncritical (Home Dir, Office program dir). When the dialog is openend the next time restore the remebered directory.
*** Issue 25935 has been marked as a duplicate of this issue. ***
according to the announcement on releases (http://www.openoffice.org/servlets/ReadMsg?list=releases&msgNo=7503) this issue will be re-targeted to OOo Later.
*** Issue 32722 has been marked as a duplicate of this issue. ***
*** Issue 41080 has been marked as a duplicate of this issue. ***
*** Issue 37485 has been marked as a duplicate of this issue. ***
*** Issue 41019 has been marked as a duplicate of this issue. ***
*** Issue 20583 has been marked as a duplicate of this issue. ***
*** Issue 19453 has been marked as a duplicate of this issue. ***
.
remove dep to 19453
Only CC Spam
*** Issue 42167 has been marked as a duplicate of this issue. ***
respectfully i'd like to nominate this issue for 2.0, 2.0.1,..
*** Issue 38613 has been marked as a duplicate of this issue. ***
Because of resource bottlenecks it is impossible to fix this for OOo 2.0. But everybody is invited to submit a patch for this Window FileOpen dialog bug. Sorry and regards, Tino
Created attachment 23636 [details] Small delphi project that has one solution
I think it has to do with the current directory setting that Windows does. As OOo is started it gets the current dir of the document. I have attached a small program with source code that makes this clear. if you press the button it changes the current directory to the exe directory and you can unmount the dir. Windows gives the complete path of the file so you are normally not interesed in the current dir.
Sorry for the amount of spam, but i forgot to explain how to test with my small program. put the exe somewhere (e.g. on your desktop) create a folder (e.g. testing) on the desktop. create a file with a strange extention (e.g. test.gxh ). rightclik on this file and select 'open with' connect the exe permanently to this filetype. doubleclick the file. he tool will show some info of the 'surroundings' of the program. try to delete the folder (this is not allowed) click the botton conviniently placed smack in the middle try to delete the folder (this is allowed, folder is gone) The same works if you put the file on a memory stick or anything else. I hope someone can put this one line of code somewhere.
*** Issue 30944 has been marked as a duplicate of this issue. ***
*** Issue 30890 has been marked as a duplicate of this issue. ***
*** Issue 38826 has been marked as a duplicate of this issue. ***
*** Issue 46659 has been marked as a duplicate of this issue. ***
*** Issue 46782 has been marked as a duplicate of this issue. ***
set prio P4 -> P3, because of amount of duplicates
*** Issue 48221 has been marked as a duplicate of this issue. ***
*** Issue 48634 has been marked as a duplicate of this issue. ***
*** Issue 50459 has been marked as a duplicate of this issue. ***
Reassigned for change of responsibilities sake.
*** Issue 50707 has been marked as a duplicate of this issue. ***
*** Issue 50088 has been marked as a duplicate of this issue. ***
*** Issue 55471 has been marked as a duplicate of this issue. ***
*** Issue 55742 has been marked as a duplicate of this issue. ***
*** Issue 59066 has been marked as a duplicate of this issue. ***
*** Issue 62590 has been marked as a duplicate of this issue. ***
Based on number of duplicate Issues (20+ !) and Votes, can we please set a Target milestone... Regards, Andrew
The behaviour is an implementation detail of the Windows system file open dialog (Black box). It sets the process CWD to the last selected path. This locks the path f.e. you won't be able to remove a CD from the drive. You'll experience the same when you are using Notepad, Wordpad or even Microsoft Office (beside their dialogs are a reimplementation of the Windows system dialogs). This is common on Windows for most applications due to Windows internals and can easily be workarounded by traveling to another directory with the FO-Dialog.
sometimes it would be less work to fix the issue than to close a lot of duplicates, discuss with users and tell constantly the same things. Yes .. it is a windows issue, that should be fixed in Windows. But ok .. if we want to have to have another 20 duplicates before getting this fixed .. may it be.
*** Issue 62492 has been marked as a duplicate of this issue. ***
i think that target 3.0 is not appropiate for this bug (special kind of issue). I suggest setting it for 2.0.x (probably 2.0.3 because 2.0.2 it's in RC)
*** Issue 44712 has been marked as a duplicate of this issue. ***
Created attachment 38055 [details] proposed patch
The file I attached is a proposed patch, applies to file fpicker/source/win32/filepicker/getfilenamewrapper.cxx only (gsl then ?); I built it with 2.0.3 sources. I checked it on Windows XP Home, using a USB stick and there it worked. I used two functions from the Visual C++ CRT (_wgetcwd / _wchdir) and I choose an automatic variable as a temporary buffer to store the path before calling the standard Windows dialogs. The temporary path buffer size is fixed to 1500 characters, so with (unpratical I think) long paths the bug will show up again. A better solution could have been using malloc/free for a better buffer management, but I didn't know there in win32 interface if that was safe (fragmentation, trashing, etc..). According to the documentation I have with the compiler, _wgetcwd / _wchdir are OK for Windows NT, 2000, XP and Unicode. I'm not sure of unicows.dll effects about this on Win 98, Me, 95. A better implementation would have been forcing a fixed path on exiting the Windows function, but I don't know how to pick up a suitable path (the default user path or the application start path), especially from inside win32 abstraction layer. I can do this if someone gives me some direction, though. To test, do as described at the beginning of the issue, but this time as soon as OOo closes the document, the stick can be unmounted (using the icon to the desktop lower right).
Issue type PATCH, target 2.x...
beppec56: could you check if your patch does not break expected behaviour? The file open / save dialog should always show the path, where the recent document has been loaded from / saved to. (tnanks for taking care about this nasty issue)
Created attachment 38091 [details] updated version, built against m178.
-> andreschnabel. The patch doesn't touch the behaviour of the FileOpen/Close/SaveAs Windows dialog. I checked it and as far as I can tell it runs. After applying this patch an issue remain in a special circumstance: 1. begin with no OOo and no quickstart; 2. insert USB stick; 3. navigate to the OOo file and double click. 4. after you close the file, you need to close OOo and the quickstart to umount the stick. But: 1. have the quickstart ready (at the logon, as per default install); 2. insert stick; 3. navigate to the file to open, double click; 4. after you close the file you'll be able to unmount the stick, leaving OOo and quickstart in place.
Sorry I didn't mention how I checked: Windows XP Home SP2, patch backported to OOo 2.0.3
in reply to #55, see my comment #25. Windows sets the current folder of the application to the folder where the file comes from.
In principle the patch is O.K. but I would prefer to remember the CWS before every call to GetXXXFileName and reset it afterwards instead of defaulting to the WINDOWS directory. We'll try to fix this in the next release.
*** Issue 68801 has been marked as a duplicate of this issue. ***
*** Issue 69435 has been marked as a duplicate of this issue. ***
-> hro. Sorry, to be late in answering; anyway, what do you mean by CWS in #desc58? I suppose it's the OOo Windows workspace, not the CWS in OOo development slang, right? I thought to force the working directory to the OOo binary directory (e.g. <OOo dir>/program) since this is the only one that must be there throughout the OOo run time, but then I couldn't devise a method to retrieve it from inside a win32 abstraction layer module (e.g. what OOo function to call). May be I can help ? I have CVS and CWS ( OOo slang this time ;-) ) access.
*** Issue 70577 has been marked as a duplicate of this issue. ***
kso->all: hro is currently sick and will not be available before January 2007. That's why there is currenly no actual activity here.
As this issue is really important and we even have a patch already I tried to find a replacement for hro. Thankfully mav will take this over. Target adjusted.
Mikhail, though hro wanted to improve the patch a bit I think that we should no longer wait or try to understand what he might have wanted to do. He said that the patch looks OK and if you don't find a problem in it please apply it. If hro wants to optimize something he can do it later but we shouldn't wait any longer for getting this painful issue fixed (even if it is a Windows problem and not an OOo problem).
I have implemented the solution suggested by hro, and have used the patch solution as a fallback. mav->beppec56: As I understand, hro had meant the current directory when he had used "CWS" term in his last comment, in other words he wanted to remember the current directory before every call to GetXXXFileName and reset it afterwards.
MAV->TM: Please verify the issue.
*** Issue 69907 has been marked as a duplicate of this issue. ***
Checked and verified in cws fwk56 -> OK !
closing ancient issues
*** Issue 74558 has been marked as a duplicate of this issue. ***
Now version 2.4 is out. The bug is still inside. I used Win XP SP2 OOo 2.4. Create a local directory, copy a file to it, open it with OO, close it, and you are not able to remove the directory unless you close everything from OO. Best regards, Bernd
Reopening.
hro: Seems, that we managed to break the fix we once made. Please take a over.
Accepted.
hro: no time to fix this for 3.0. Sorry, need to re-target to 3.1.
*** Issue 96812 has been marked as a duplicate of this issue. ***
Not enough time to fix for 3.1
cd: Please take over.
cd: I have to adapt the file picker for Windows 7. So it makes sense to fix this issue, too.
cd: I have too much issues to fix all of them for OOo 3.2. Due to missing time this issue must be moved to the next release OOo 3.3.
cd->mav: Please take over. You fixed the issue some years ago and have a better understanding what must be done/what could be broken.
I can not reproduce the problem in OOo3.3.
mav->tm: Please verify the issue in OOo3.3 and close it in case it is not reproducible. Otherwise please send the issue to me back.
adding me to CC list
worksforme -< closed