Bug Hunting Session
Bug 100877 - After closing of LO documents, .lock files sometimes do not get deleted
Summary: After closing of LO documents, .lock files sometimes do not get deleted
Status: RESOLVED DUPLICATE of bug 43883
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
5.1.4.2 release
Hardware: All Windows (All)
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-07-12 17:18 UTC by sov.info
Modified: 2016-07-29 12:35 UTC (History)
2 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 sov.info 2016-07-12 17:18:25 UTC
Description: I can use LibreOffice programs (Writer, Draw, Calc) for opening various files. When these files opened, a hidden system duplicat creates in file's directory and after closing the program it should successfully be deleted. However, this not always happens and this file doesn't deleted.
Comment 1 Buovjaga 2016-07-18 14:51:37 UTC
This only happens, if LibreOffice crashed. Did it happen after a crash?
Comment 2 sov.info 2016-07-18 15:40:22 UTC
(In reply to Buovjaga from comment #1)
> This only happens, if LibreOffice crashed. Did it happen after a crash?

No. I close documents normally, but if i open several docs (~15), the probability of appearance of this unused file is higher.
Comment 3 Buovjaga 2016-07-19 12:26:21 UTC
There are "stealth crashes", but now with the crash reporter of 5.2 they can be seen better: bug 100870 is an example.
Maybe you could install 5.2 RC2 and try to reach your .lock file situation and hopefully it turns out to be a crash: http://www.libreoffice.org/download/pre-releases/
Comment 4 sov.info 2016-07-29 03:17:10 UTC
I install LibreOffice 5.2.0.3 x86. with russian HelpPack.
I could make it crash with doc files http://storage7.static.itmages.ru/i/16/0729/h_1469761823_7308030_c412284767.png

After clicking on OK, program closes. and creates files .~lock (for example, .~lock.tabak.doc#)
containing path, PC name and date

,admin-nb/EAGLE,admin-nb,29.07.2016 07:11,file:///C:/Users/EAGLE/AppData/Roaming/LibreOffice/4;

After reopening program, i choose not to recover documents. So these lock files deletes. OK.

I could make program crash with 100% probability by opening 15 pptx-files, and lock files not always deletes.

http://storage6.static.itmages.ru/i/16/0729/h_1469761822_2262164_c14dd0e057.png

On 5.2.0.3 version i don't see any temp files starting with $ symbol yet (as it was on stable version 5.1.4.2)
Comment 5 sov.info 2016-07-29 03:22:20 UTC
It seems, lock files after doc-files does not always deletes, too. I just noticed it.
Comment 6 sov.info 2016-07-29 03:25:46 UTC
Possibly related bug (if not the same):

https://bugs.documentfoundation.org/show_bug.cgi?id=43883
Comment 7 Buovjaga 2016-07-29 07:34:31 UTC
(In reply to sov.info from comment #6)
> Possibly related bug (if not the same):
> 
> https://bugs.documentfoundation.org/show_bug.cgi?id=43883

Aha, did you investigate the difference between opening files from Windows explorer versus from LibreOffice? If you are sure it is the same, you can close this report as a duplicate of 43883.
Comment 8 sov.info 2016-07-29 10:08:30 UTC
Yeah, it probably the same, and my bug (trash in directories after opening files in Explorer) is a continuation of bug 43883. But i try opening my ppt files (those that crash LO with 100% probability) in program (not by explorer) - and lock files still here , in directory. But this happens only after program crash and after i refuse to made any recovery to files. Lock files should be deleted anyway, but it doesn't happen, right?
Comment 9 Buovjaga 2016-07-29 12:35:49 UTC
(In reply to sov.info from comment #8)
> But this happens only
> after program crash and after i refuse to made any recovery to files. Lock
> files should be deleted anyway, but it doesn't happen, right?

No, lock file do not get deleted after a crash. Let's close as dupe, then.

*** This bug has been marked as a duplicate of bug 43883 ***