Created attachment 132854 [details] 2 "Document in Use" windows for a odt and a docx file The attached file shows 2 different "Document in Use" dialog windows. The first one is displayed when opening a locked OpenDocument file and shows the 3 buttons "Open Read-Only", "Open Copy" and "Cancel". That's self-explanatory and works well. The second one is displayed when opening a locked docx file and shows the 3 buttons "Open Read-Only", "Open" and "Cancel". As described in the window, "Open" means that the file will be opened anyway regardless of whether the file is in use/locked or not. But clicking "Open" opens the file in the same way as "Open Read-Only": Read-only and showing the yellow info bar. If I click at "Edit document" in the yellow info bar, LibreOffice asks me in a dialog window without a title "This document cannot be edited, possibly due to missing access rights. Do you want to edit a copy of the document?". The rights on the file are OK, it's only a problem of already-being-in-use in another program. -> This second question should have been handled in the "Document in Use" dialog before. There may be use cases where the 2 separate dialog windows are OK but that should be handled in a better way so that a user hasn't to click through several dialog windows if it's not necessary. Version: 5.3.2.2 Build ID: 6cd4f1ef626f15116896b1d8e1398b56da0d0ee1 CPU Threads: 8; OS Version: Windows 6.2; UI Render: default; Layout Engine: new; Locale: de-DE (de_DE); Calc: CL In version 5.1.4.2 (x64) there is only a single form of the "Document in Use" window -- the second window at my screenshot isn't available -- which was the better solution in my use case.
Confirmed, but I don't get the "Edit document" info bar upon "Open" for a locked docx. Arch Linux Version: 5.3.2.2 Build ID: 5.3.2-3 CPU Threads: 8; OS Version: Linux 4.10; UI Render: default; VCL: kde4; Layout Engine: new; Locale: fi-FI (fi_FI.UTF-8); Calc: group
Please retest with actual version. I have the dialog with "Open Copy" in LO 6, Win7,
Nothing changed for me. Version: 6.0.0.0.alpha0+ Build ID: 5ea1b4c336d1cad92dc18e7cf7e4b381396f448b CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk3; Locale: de-DE (de_DE.UTF-8); Calc: group auto updater build from today.
Hm, the dialog mentioning a "different system" should be indicative of something else, that it's accessed from different computers, was that the case perhaps? And is it possible the testing in different versions happened slightly differently? So far my experience is the same as raal's when I checked in Windows. Then again, lots of complicated stuff happen when evaluating file locking/lock files depending on whether native locking is supported or not, whether the file is accessed by the same/another user or from the same/different system, and who knows what else.
Ok, so the dialog on the right is shown for example if there is a lock file, but the document itself is not locked by the system.
I tested it on Ubuntu Linux and there the "Open" button has the correct meaning (it's "stealing" the edit mode from the other instance). I never noticed this behavior at work on different Windows machines (from XP to 10) and I think it's because I'm working on Windows network drives instead of local drives. There, the locking/unlocking feature isn't apparently working.
(In reply to Thomas Lendo from comment #6) > I tested it on Ubuntu Linux and there the "Open" button has the correct > meaning (it's "stealing" the edit mode from the other instance). There are three kinds of behaviors when opening a file based on what is in the lock file (provided the file isn't actually locked): - if all the details are the same as your current user and profile, the file will open without question, - if the profile location is different, the program will assume that the same user had the file open from a different system, and will let them open the file for editing, - if the user name is different, the program will assume the file is locked by someone else, and will only allow opening it in read-only mode, or as a copy. Of course file system locks can override user action, there's no real way to "steal" edit mode if a file system lock is in place (unless by tinkering on OS level).
Aron, I never thought about file system lock when writing this bug report. I only mean locking due to a LibreOffice instance. For me, it's still a regression as it worked well until LibO 5.1.
(In reply to Thomas Lendo from comment #8) > For me, it's still a regression as it worked well until LibO 5.1. Unfortunately I cannot see a reliable reproducing steps to be able to test. As Aron has already explained, two things are considered when the dialogs are chosen: if there is a lock OO-style file present; and if the document is locked at filesystem level (i.e., out of the scope of LibreOffice). The logic is that if the document is not FS-locked, but the lockfile is present, then we might suspect that the lockfile might be stale from some crash, so it had only been left by mistake; and in this case, we can suggest to ignore the lockfile. But if the lockfile is accompanied by FS-lock, then we see that the file is indeed used right now by some other application, and so we don't offer an option to override the lockfile. But I can imagine a situation when (esp. in multiuser environment) a document had been checked to have no FS lock; but the lockfile is already present. Then user decides to ignore the lock, so file is tried to open in RW mode. But in the meantime, the document had been already locked by another application, so the attempt failed, and RO mode resulted. I even can imagine that happening because of concurrent MSO installation - imagine this sequence: 1. User double-clicks a DOCX document on a network share, which has a stale lockfile from a previous LO session. 2. LO checks the document file, sees no FS lock on it, but detects the lockfile, and offers to override the lockfile. 3. In the meantime, a timeout elapses that prevents immediate file info display in Explorer for files on network shares (the timeout prevents lags when working with files on low-latency filesystems); the DOCX document that had been selected in Explorer by double-click is started to be analysed by associated shell extension (simply put, a MSO component opens it in the background to extract author/stats/preview); and file gets locked for the time being (the network latency might make this a lengthy operation). 4. User clicks "Open". 5. File cannot be open for editing - RO mode.
(In reply to Mike Kaganski from comment #9) > (the timeout prevents lags when working with files on low-latency filesystems) Of course, high-latency was meant; sorry for the mistake.
Aron and Mike, thank you very much for your explanations. After the long time, I can't reproduce a window with "... different system ..." with version 6.3.6.2, 7.0.0 RC1 and 7.1.0.0.alpha0+ (Build ID: ffe503b62f9a508285ed06ef977f91604130579a). And there is no dialog window anymore after clicking on "Edit document" in the blue info bar. I close the bug now. If somebody has new input, the bug can be reopened to NEW anytime.