I am grateful for the discussion, I think many bits are now clear. I see the topic is drifting to level of personal preferences: whether you're used to locking and if the locking is natural (because you deal with it for years) or superficial and usability burden. I am acknowledging tools like the Unlocker Assistant might be a part of workflow for many... but it shouldn't be part of a casual user's toolset.
Actuallly on Windows you need to open the file for writng to test locking, don't you. Example of the trick: https://social.msdn.microsoft.com/Forums/vstudio/en-US/59d584d6-0b6a-47c1-aafe-338063162b9b/how-to-test-if-a-file-is-locked-without-locking-it-?referrer=http://social.msdn.microsoft.com/Forums/vstudio/en-US/59d584d6-0b6a-47c1-aafe-338063162b9b/how-to-test-if-a-file-is-locked-without-locking-it-?forum=vcgeneral Does this overwrite the file? Then what if export failed? Hint:saving this way is not atomic operation. Rob has mentioned what the natural behavior is, I'll add: By thinking outside of the box, the result is more or less as follows. 1. If there's existing file of the same name, on export you're either confirming overwriting or picking a new name (as in save as). More specialized software can even pick a new name automatically based on the document/data name at hand. 2. Once you agreed with overwriting it *does not matter* one or 10 apps opened old version of the file before. They should be implemented in a way that lets them still to operate, what is possible by either loading entire file to memory as in Notepad or moving/extracting to a temporary file (e.g. various Photoshop-like apps sometimes deal with a gigabyte file). None of them need to lock a file exclusively for just reading. They sometimes do so, and the reason is that WinAPI (I say it again: coming from DOS times) advertises file locking. There may be races but in interactive programs it's unlikely that I trigger export to the same name file twice in the same second. Preference for locking for no sane reason cause situations when files are locked on a Windows file share and emails are circulating. Have you ever seen this happening on the Internet or on your mobile phone? (and even it's not Windows Phone anymore because it's built kind-of from scratch without these DOS idioms of these sort I guess) Locking for the discussed purposes is a cheap and quite naive replacement for proper design of a workflow (here: phases of document editing and previewing, where multiple apps are have to "cooperate" somehow to get the work done). If nobody approaches Adobe that the reader's behaviour is bad they would never know. There's also interesting observation about double standards: that people move to LO from MS Office but stay with properietary PDF readers and deal with their specifics when alternatives exist. For me the bug is a WONTFIX and belongs to Acrobat and alikes. PS: That said I am not claiming locking isn't useful. In Kexi on Windows (and elsewhere) I am attempting to lock the .kexi file on opening (only read/write) if possible because of the way it's used: it's a database file with random access to blocks, in general case not entirely loaded to RAM or copied to a temp file. This is unlike in LO Base which non-atomically extracts/copies to contents. So this is a one-file - one-app model, and the file is not meant to be used over network (MS Access performance issues have no place here). On 1 December 2014 at 06:35, Brian Barker <[email protected]> wrote: > At 19:56 30/11/2014 +0100, Jaroslaw Staniek wrote: >> >> On Sunday, 30 November 2014, Brian Barker wrote: >>> >>> At 13:55 30/11/2014 +0100, Jaroslaw Staniek wrote: >>>> >>>> Google for "acrobat reader file locking" and you'd notice that this >>>> unnecessary locking is inherent issue of Windows. You're dealing with >>>> behavior largely inherited from the MS DOS era. You can pick other pdf >>>> reader. >>> >>> >>> Surely that evidence falsifies your claim? If it's possible for another >>> reader under the same operating system not to lock the file, then the >>> locking cannot be a property of the operating system, still less of its >>> legacy? In fact, it cannot be: just look at Windows' Notepad, which does not >>> lock files it opens. >> >> >> Opening for writing locks the on Windows. > > > Do you mean that all Windows software capable of editing document files > locks them? Sorry, but that is simply untrue - as I suggested. See > http://en.wikipedia.org/wiki/Notepad_(software) : "Notepad does not require > a lock on the file it opens, so it can open files already opened by other > processes, users, or computers...". So this is surely not about any > difference between operating systems? In any case, file locking is surely in > general a Good Thing, isn't it? LibreOffice locks document files against > opening in another instance of LibreOffice in its own way (under whatever > operating system). The question here should surely be whether you want a PDF > reader that is capable of annotation (and therefore of writing to document > files), and if you do, how you want it to behave. > >> Linux informs that the file was changed or removed if it editing it, that >> models the real world. > > > So you mean that I can spend a couple of hours editing a file, only to > discover when I try to save the result that you have been editing it as > well, and I have the choice of either overwriting your changes or abandoning > mine? That's not part of any "real world" I want to inhabit. > >> Perhaps argument about other readers suggests that the bug should be >> filled against the Adobe app, not LO. > > > Sort of. If you need just a reader, you may prefer something that isn't > capable of editing (such as annotation) - so not Adobe Reader, despite its > name. But the original suggestion was that LibreOffice should make a better > fist of handling the lock when it exists. > >> The wish for a special message looks for me like asking for usability-wise >> unfortunate "solution" where LO would ask the user to close the file. > > > Yes, just as happens in many other contexts - installing software, for > example. > >> In this scenario LO doesn't even know who's locking ... > > > Which is why it would ask the user for decision and action. > >> ... and how to communicate the intent to unlock. > > > The suggestion is not that LibreOffice should override the lock, but that it > should report the problem gracefully to the current user - by error message. > >> All that made me write about core problem - pessimistic locking on >> DOS/Windows. > > > I don't see how you can blame the operating system. (See above.) Oh, and I > think you'll find that LibreOffice is not available for DOS. > >> Not talking about the context - the OS - leads to situation that apps on >> normally behaving oses show unexpected messages that really make sense for >> Windows. Extra care is needed to avoid that. > > > If LibreOffice were to detect the lock, it would not see one if there were > no lock. Why do you think it would produce a message about a lock it didn't > detect? Do you underestimate the designers? > >> I'm not studying the pdf export code of LO but proper development practice >> is to write the new file to a temporary path, then renaming it atomically. >> If that's true the message would appear on the very end anyway. > > > But it *could* establish if there was a lock at the beginning of the > process. That's the suggestion (about which I make no comment). > > > Brian Barker > > -- > To unsubscribe e-mail to: [email protected] > Problems? > http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ > Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette > List archive: http://listarchives.libreoffice.org/global/users/ > All messages sent to this list will be publicly archived and cannot be > deleted > -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek -- To unsubscribe e-mail to: [email protected] Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/users/ All messages sent to this list will be publicly archived and cannot be deleted
