Bug 92817 - misleading error on save with empty lock-file ...
Summary: misleading error on save with empty lock-file ...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: framework (show other bugs)
Version:
(earliest affected)
5.0.0.0.beta1
Hardware: Other All
: medium normal
Assignee: Mike Kaganski
URL:
Whiteboard: ToBeReviewed target:5.2.0 target:5.3....
Keywords: difficultyBeginner, easyHack, skillCpp, topicCleanup
Depends on:
Blocks: File-Lock
  Show dependency treegraph
 
Reported: 2015-07-18 19:41 UTC by Michael Meeks
Modified: 2017-12-07 07:23 UTC (History)
1 user (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 Michael Meeks 2015-07-18 19:41:35 UTC
If you unluckily have run out of space, then LibreOffice happily looses your document data (it appears). But more annoying than that it also then mis-behaves with an zero-length (or incorrectly populated) lock-file.

If you do:

touch /tmp/.~lock.empty.ods\#

and try to save a file as /tmp/empty.ods

You get this grim error:

"Error saving the document Untitled1:
Object not accessible.
The object cannot be accessed
due to insufficient user rights."

But of course - the user has all rights to both the lock-file, directory etc.

In this case we should show the 'open copy' etc. dialog and carry on.

The log trace from this:

.config/libreoffice/4/user/temp/document_io_logring.txt

for 4.4 says:

Rethrow
/home/timar/core/sfx2/source/doc/objstor.cxx:1325: SaveAs/Export
/home/timar/core/sfx2/source/doc/objstor.cxx:1338: Locking
/home/timar/core/sfx2/source/doc/docfile.cxx:914:
/home/timar/core/sfx2/source/doc/objstor.cxx:2878:
/home/timar/core/sfx2/source/doc/objmisc.cxx:260: Resetting Error.
/home/timar/core/sfx2/source/doc/sfxbasemodel.cxx:3124: Storing failed!

Which to me says the problem most likely lurks aroudn here:

core/sfx2/source/doc/docfile.cxx:914:

(ignoring /home/timar)

Worth digging for this case through the docfile.cxx and locking code - to nail it I guess =)

Thanks !
Comment 1 tux3 2015-08-09 12:21:37 UTC
I can reproduce the bug, and I think I see where the error appears, but I'm not sure what to do with it.

>In this case we should show the 'open copy' etc. dialog and carry on.

I assume you mean this one: https://i.imgur.com/JhNQmKU.png, but I'm not sure how the 'open copy' dialog helps. The choices "Open Read-Only" and "Open Copy" don't really make sense since we're trying (and failing) to save a file.

So I can see two options, either cancel and have the user save somewhere else, or kill the invalid lock, carry on with the saving, and hope nothing goes wrong.

Should there be a new dialog box for this? Should we just silently discard invalid locks?
Comment 2 Robinson Tryon (qubit) 2015-12-10 11:41:02 UTC Comment hidden (obsolete)
Comment 3 Robinson Tryon (qubit) 2016-02-18 14:51:37 UTC Comment hidden (obsolete)
Comment 4 Michael Meeks 2016-03-23 11:09:49 UTC
tux3: surely you're right - my description was far from ideal ;-)

Still - luckily we managed to get this fixed; nice work [!]
Comment 5 Commit Notification 2016-03-23 11:37:33 UTC
Jaskaran committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=8d411a4a1ef6844c00bc714f8b144d3729e4f4e8

tdf#92817 Fix for Error on Save with empty lock file

It will be available in 5.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 6 Mike Kaganski 2016-10-14 14:33:46 UTC
The committed fix causes a regression. If ooousername in the lockfile happens to be empty (user hadn't filled in relevant information in LO), then the lockfile generated by that user is always treated as "empty" (=own) by any other LO.

A revised patch submitted for review: https://gerrit.libreoffice.org/29834
Comment 7 Commit Notification 2016-10-14 14:51:00 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=c3fa866e768b67650b1e52308565e9344db0b4b4

tdf#92817: re-implement empty lockfile fix

It will be available in 5.3.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 8 jani 2016-10-16 12:53:19 UTC
Seems solved
Comment 9 Commit Notification 2016-10-17 10:00:50 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "libreoffice-5-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=4af1ac3a9a773e4875712dd2f43f06a1a4edcc19&h=libreoffice-5-2

tdf#92817: re-implement empty lockfile fix

It will be available in 5.2.4.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 10 Commit Notification 2016-10-25 11:14:59 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "libreoffice-5-2-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=a6ea499e9e22055d421b08c2536b5cfe23f1b25a&h=libreoffice-5-2-3

tdf#92817: re-implement empty lockfile fix

It will be available in 5.2.3.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.