Bug 43883 - LibO started via Windows Explorer does not release lock on directory when file is closed (win only)
Summary: LibO started via Windows Explorer does not release lock on directory when fil...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
3.4.4 release
Hardware: x86 (IA32) Windows (All)
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 100877 (view as bug list)
Depends on:
Blocks: Desktop-Integration
  Show dependency treegraph
 
Reported: 2011-12-16 05:24 UTC by Ed
Modified: 2019-07-16 11:39 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ed 2011-12-16 05:24:35 UTC
This is on Windows XP.  

This happens when you start LibreOffice from Windows Explorer by using Windows' file type associations: you double-click on a LibreOffice file in Windows Explorer and it opens that file in LibreOffice.  If you then close the file in LibreOffice (but leave the application running), the lock on the file is correctly released, and it can then be deleted, for example.  However, LibreOffice retains a lock on the directory from which the file was opened, and, even with the file closed, you cannot delete the directory while LibreOffice is still running.  

To reproduce:
- create a new directory anywhere
- copy any LibreOffice file to this directory
- with LibreOffice not already running, double-click (or press Enter) on this file
- observe the file correctly opens in LibreOffice
- close the file in LibreOffice, but leave LibreOffice running
- in Windows Explorer, attempt to delete the file you have just opened and closed
- observe this happens correctly
- now attempt to delete the directory you created
- observe that this throws an error ("Cannot delete <dirname>: It is being used by another person or program" on Windows XP)

I would suggest that when LibreOffice is started this way, it should not place a lock on the directory from which it is started.  Alternatively, if it must place such a lock, it should release it when the file is closed.  

This problem does not occur if you start LibreOffice from the Start Menu, then open a file either using the LibreOffice menu or via Windows Explorer.
Comment 1 Agnieszka 2012-01-03 13:33:34 UTC
When you start LibreOffice from Windows Explorer by using Windows XP and you have just opened and closed a LibreOffice file. If you then close the file in
LibreOffice, but leave the application running, you can not delete the directory. You see the error: "Cannot delete <dirname>: It is being used
by another person or program".
Comment 2 ign_christian 2013-06-21 05:48:18 UTC
Still reproducible on LO 4.0.4.2 & Win7 Home Premium 32bit, not only on XP.

Directory/folder still locked by LO though it's empty.
Comment 3 Andrew Martin 2014-03-25 13:53:38 UTC
I've experienced a very similar problem accessing files on a Samba share (Samba 3.6.3) on Windows 7 Professional amd64 and using LibreOffice 4.0.5.2. After a reboot if I navigate to the share and open the file, it opens correctly the first time. I then close it, and no lock file remains. Also, running smbstatus on the server does not show the LibreOffice file as being open. However, when I double-click on it again in explorer, I get the warning that it is locked by unknown user. If I instead open LibreOffice and go to File - Open, it opens successfully without the error.
Comment 4 Lionel Elie Mamane 2014-04-07 15:15:38 UTC
FWIW, the Windows Notepad has the same behaviour.

My guess is that this is the "currently active directory" which is never changed after startup. On GNU/Linux (and other Unix clones) it does not matter that much because a used directory can be unlinked (becomes unreachable (invisible) from the filesystem and will automatically be effectively deleted when closed by the last program having it open). With Windows' approach of "refuse to delete something in use", well, this becomes visible.
Comment 5 QA Administrators 2015-06-08 14:42:13 UTC Comment hidden (obsolete)
Comment 6 Ed 2015-06-08 18:52:41 UTC
Sorry, I no longer have access to a Windows machine on which to test this.  For anyone who does, it will be /extremely/ simple to do.
Comment 7 Buovjaga 2015-06-19 16:44:06 UTC
Confirmed.

Win 7 Pro 64-bit Version: 5.1.0.0.alpha1+
Build ID: 437210d58f32177ef1829d704f7f4d2f1bbfbfdd
TinderBox: Win-x86@39, Branch:master, Time: 2015-06-18_07:21:56
Locale: fi-FI (fi_FI)
Comment 8 Buovjaga 2016-07-29 12:35:49 UTC
*** Bug 100877 has been marked as a duplicate of this bug. ***
Comment 9 QA Administrators 2017-09-01 11:16:06 UTC Comment hidden (obsolete)
Comment 10 Thomas Lendo 2018-10-18 07:42:17 UTC
I can't reproduce on Windows 10 with

Version: 6.0.6.2 (x64)
Build-ID: 0c292870b25a325b5ed35f6b45599d2ea4458e77
CPU-Threads: 8; BS: Windows 10.0; UI-Render: Standard; 
Gebietsschema: de-AT (de_AT); Calc: group

Closing as RESOLVED WORKSFORME.

If you still have this problem, please reopen as NEW.
Comment 11 nisha 2018-10-30 06:25:37 UTC Comment hidden (spam)
Comment 12 aadil khan 2019-07-16 11:39:21 UTC Comment hidden (spam)