Re: [libreoffice-users] PDF export checking whether the file is locked (opened) by another program before starting exporting over it
Op 1 dec. 2014, om 06:35 heeft Brian Barker het volgende geschreven: 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. No, you get the option to either 'save as' or quit without save. This is also true in some traditional editors in Unix/Linux like emacs. 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: users+unsubscr...@global.libreoffice.org 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 -- To unsubscribe e-mail to: users+unsubscr...@global.libreoffice.org 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
Re: [libreoffice-users] PDF export checking whether the file is locked (opened) by another program before starting exporting over it
At 11:55 01/12/2014 +0100, Rob Jasper wrote: Op 1 dec. 2014, om 06:35 heeft Brian Barker het volgende geschreven: 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. No, you get the option to either 'save as' or quit without save. This is also true in some traditional editors in Unix/Linux like emacs. But that has exactly the same problem as I was suggesting. I've been editing for a couple of hours, expecting to be doing useful work, only to find when I come to save that you have also been editing independently. Now either of your options is unsatisfactory: either the work that I have done is wasted or else we end up with two separate documents and the job of somehow merging them later. I needed to know before I started editing that my work would be wasted and that I should hold back until you had created your next version. A lock on the file enables any user to appreciate the problem in advance - which is not dissimilar to the original suggestion about exporting as PDF. Brian Barker -- To unsubscribe e-mail to: users+unsubscr...@global.libreoffice.org 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
Re: [libreoffice-users] PDF export checking whether the file is locked (opened) by another program before starting exporting over it
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 b.m.bar...@btinternet.com 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),
Re: [libreoffice-users] PDF export checking whether the file is locked (opened) by another program before starting exporting over it
Hi Everyone, I see that an exact issue already exists since 08/2012!!! https://bugs.freedesktop.org/show_bug.cgi?id=53530 I think it could be a user time saving big fix and it could be a very appreciated update/fix in professional job/activities too. I also currently don't know if the same behaviour happen on other environment like linux and/or MacOS X. I think the pdf file state could be test other than the mere existence, couldn't it? Have a nice Sunday, Carlo -- ing. Carlo Strata - via Botticelli 1/4 30031 Dolo - VE Italia - Italy - tel. +39.041.822.0665 cell. +39.347.85.69.824 Skype carlo.strata Google carlo.strata.69 - carlo.str...@tiscali.it PEC: carlo.str...@ingpec.eu Il 29/11/2014 13:27, Carlo Strata ha scritto: Hi Everyone, I use LibreOffice for all my job activities and I yield many pdf documents. Many time I change the original document and update the associate pdf. If I forget (!) to close the pdf document on my viewer (see below), not necessarily the viewer itself, I get a nice sequence of I/O errors and the export operation obviously fails! If I export a long document I have to repeat the long time operation and to waste my time. So, why not check whether the file is locked (opened) by another program before (!) starting exporting over it? I think it is possible. Wht do you think about? Is there already an issue about this behaviour? My current work environment is: - Microsoft Windows 8.1, 64 bit, Ita gui, daily full updated; - LibreOffice 4.3.5.1, win32, Ita gui and local help; - Adobe Acrobat Reader XI, 11.0.09, win32. Have All a nice weekend, Carlo -- To unsubscribe e-mail to: users+unsubscr...@global.libreoffice.org 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
Re: [libreoffice-users] PDF export checking whether the file is locked (opened) by another program before starting exporting over it
Hi, 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. Or publish to a web server and open the file using web browser -it's lockless. If you ask about Linux, it was solved *properly* years ago. If you're a pro you can try e.g. Okular reader which reloads the pdf automatically and never locks. Why would it in a modern multiuser Inernet-enabled environment? The bug doesn't belong to LO. Error message can be added, but IMHO just to annoy users in a different way... On Sunday, 30 November 2014, Carlo Strata carlo.str...@tiscali.it wrote: Hi Everyone, I see that an exact issue already exists since 08/2012!!! https://bugs.freedesktop.org/show_bug.cgi?id=53530 I think it could be a user time saving big fix and it could be a very appreciated update/fix in professional job/activities too. I also currently don't know if the same behaviour happen on other environment like linux and/or MacOS X. I think the pdf file state could be test other than the mere existence, couldn't it? Have a nice Sunday, Carlo -- ing. Carlo Strata - via Botticelli 1/4 30031 Dolo - VE Italia - Italy - tel. +39.041.822.0665 cell. +39.347.85.69.824 Skype carlo.strata Google carlo.strata.69 - carlo.str...@tiscali.it PEC: carlo.str...@ingpec.eu Il 29/11/2014 13:27, Carlo Strata ha scritto: Hi Everyone, I use LibreOffice for all my job activities and I yield many pdf documents. Many time I change the original document and update the associate pdf. If I forget (!) to close the pdf document on my viewer (see below), not necessarily the viewer itself, I get a nice sequence of I/O errors and the export operation obviously fails! If I export a long document I have to repeat the long time operation and to waste my time. So, why not check whether the file is locked (opened) by another program before (!) starting exporting over it? I think it is possible. Wht do you think about? Is there already an issue about this behaviour? My current work environment is: - Microsoft Windows 8.1, 64 bit, Ita gui, daily full updated; - LibreOffice 4.3.5.1, win32, Ita gui and local help; - Adobe Acrobat Reader XI, 11.0.09, win32. Have All a nice weekend, Carlo -- To unsubscribe e-mail to: users+unsubscr...@global.libreoffice.org 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: users+unsubscr...@global.libreoffice.org 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
Re: [libreoffice-users] PDF export checking whether the file is locked (opened) by another program before starting exporting over it
As I understand it, the OP isn't complaining about the fact that the file is locked, rather, about the fact that LO spends (potentially a lot of) time processing the file before reporting the problem. Instead, LO could check access to the file early, and report the problem before wasting time processing. For the most common use cases, this would save the user some time. That is something that *does* belong to LO. Of course, there would still be edge cases where the file wasn't locked when LO started processing the pdf, but became locked by the time LO finished. There is nothing that can be done about that, short of LO itself locking the file, which may or may not be desired. Paul On Sun, 30 Nov 2014 13:55:37 +0100 Jaroslaw Staniek stan...@kde.org wrote: Hi, 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. Or publish to a web server and open the file using web browser -it's lockless. If you ask about Linux, it was solved *properly* years ago. If you're a pro you can try e.g. Okular reader which reloads the pdf automatically and never locks. Why would it in a modern multiuser Inernet-enabled environment? The bug doesn't belong to LO. Error message can be added, but IMHO just to annoy users in a different way... On Sunday, 30 November 2014, Carlo Strata carlo.str...@tiscali.it wrote: Hi Everyone, I see that an exact issue already exists since 08/2012!!! https://bugs.freedesktop.org/show_bug.cgi?id=53530 I think it could be a user time saving big fix and it could be a very appreciated update/fix in professional job/activities too. I also currently don't know if the same behaviour happen on other environment like linux and/or MacOS X. I think the pdf file state could be test other than the mere existence, couldn't it? Have a nice Sunday, Carlo -- ing. Carlo Strata - via Botticelli 1/4 30031 Dolo - VE Italia - Italy - tel. +39.041.822.0665 cell. +39.347.85.69.824 Skype carlo.strata Google carlo.strata.69 - carlo.str...@tiscali.it PEC: carlo.str...@ingpec.eu Il 29/11/2014 13:27, Carlo Strata ha scritto: Hi Everyone, I use LibreOffice for all my job activities and I yield many pdf documents. Many time I change the original document and update the associate pdf. If I forget (!) to close the pdf document on my viewer (see below), not necessarily the viewer itself, I get a nice sequence of I/O errors and the export operation obviously fails! If I export a long document I have to repeat the long time operation and to waste my time. So, why not check whether the file is locked (opened) by another program before (!) starting exporting over it? I think it is possible. Wht do you think about? Is there already an issue about this behaviour? My current work environment is: - Microsoft Windows 8.1, 64 bit, Ita gui, daily full updated; - LibreOffice 4.3.5.1, win32, Ita gui and local help; - Adobe Acrobat Reader XI, 11.0.09, win32. Have All a nice weekend, Carlo -- To unsubscribe e-mail to: users+unsubscr...@global.libreoffice.org 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 -- To unsubscribe e-mail to: users+unsubscr...@global.libreoffice.org 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
Re: [libreoffice-users] PDF export checking whether the file is locked (opened) by another program before starting exporting over it
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. I'm no expert, but I know that it is possible to edit some aspects of a PDF document in Adobe Reader (not Acrobat), providing this has been enabled by the document's author. http://www.adobe.com/uk/products/reader.html says Adobe Reader is capable of viewing, printing, and *annotating* PDF documents (my emphasis). Is that why Adobe Reader opts to lock the file, not knowing when you open the document whether you intend to do this? If you ask about Linux, it was solved *properly* years ago. If you're a pro you can try e.g. Okular reader which reloads the pdf automatically and never locks. Again, we should not be talking operating systems here. All you do by changing to Linux is to prevent yourself using Adobe Reader, which is not available for that system. If your chosen reader does not provide the annotating capabilities of Adobe Reader, it may indeed have no reason to lock a displayed PDF document. This may well suit your purposes better. Why would it in a modern multiuser Internet-enabled environment? When the product is capable of some modification to the file, in order to preclude update races? Brian Barker -- To unsubscribe e-mail to: users+unsubscr...@global.libreoffice.org 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
Re: [libreoffice-users] PDF export checking whether the file is locked (opened) by another program before starting exporting over it
On Sunday, 30 November 2014, Brian Barker b.m.bar...@btinternet.com 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. Just had to close all my IDE windows this week to move a file. Linux informs that the file was changed or removed if it editing it, that models the real world. Perhaps argument about other readers suggests that the bug should be filled against the Adobe app, not LO. 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. In this scenario LO doesn't even know who's locking and how to communicate the intent to unlock. All that made me write about core problem - pessimistic locking on DOS/Windows. 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. 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. Cheers! -- 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: users+unsubscr...@global.libreoffice.org 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
Re: [libreoffice-users] PDF export checking whether the file is locked (opened) by another program before starting exporting over it
This is exaclty what I meant, Paul! I completely agree with you! Carlo ing. Carlo Strata - via Botticelli 1/4 30031 Dolo - VE Italia - Italy - tel. +39.041.822.0665 cell. +39.347.85.69.824 Skype carlo.strata Google carlo.strata.69 - carlo.str...@tiscali.it PEC: carlo.str...@ingpec.eu Il 30/11/2014 14:43, Paul ha scritto: As I understand it, the OP isn't complaining about the fact that the file is locked, rather, about the fact that LO spends (potentially a lot of) time processing the file before reporting the problem. Instead, LO could check access to the file early, and report the problem before wasting time processing. For the most common use cases, this would save the user some time. That is something that *does* belong to LO. Of course, there would still be edge cases where the file wasn't locked when LO started processing the pdf, but became locked by the time LO finished. There is nothing that can be done about that, short of LO itself locking the file, which may or may not be desired. Paul On Sun, 30 Nov 2014 13:55:37 +0100 Jaroslaw Staniek stan...@kde.org wrote: Hi, 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. Or publish to a web server and open the file using web browser -it's lockless. If you ask about Linux, it was solved *properly* years ago. If you're a pro you can try e.g. Okular reader which reloads the pdf automatically and never locks. Why would it in a modern multiuser Inernet-enabled environment? The bug doesn't belong to LO. Error message can be added, but IMHO just to annoy users in a different way... On Sunday, 30 November 2014, Carlo Strata carlo.str...@tiscali.it wrote: Hi Everyone, I see that an exact issue already exists since 08/2012!!! https://bugs.freedesktop.org/show_bug.cgi?id=53530 I think it could be a user time saving big fix and it could be a very appreciated update/fix in professional job/activities too. I also currently don't know if the same behaviour happen on other environment like linux and/or MacOS X. I think the pdf file state could be test other than the mere existence, couldn't it? Have a nice Sunday, Carlo -- ing. Carlo Strata - via Botticelli 1/4 30031 Dolo - VE Italia - Italy - tel. +39.041.822.0665 cell. +39.347.85.69.824 Skype carlo.strata Google carlo.strata.69 - carlo.str...@tiscali.it PEC: carlo.str...@ingpec.eu Il 29/11/2014 13:27, Carlo Strata ha scritto: Hi Everyone, I use LibreOffice for all my job activities and I yield many pdf documents. Many time I change the original document and update the associate pdf. If I forget (!) to close the pdf document on my viewer (see below), not necessarily the viewer itself, I get a nice sequence of I/O errors and the export operation obviously fails! If I export a long document I have to repeat the long time operation and to waste my time. So, why not check whether the file is locked (opened) by another program before (!) starting exporting over it? I think it is possible. Wht do you think about? Is there already an issue about this behaviour? My current work environment is: - Microsoft Windows 8.1, 64 bit, Ita gui, daily full updated; - LibreOffice 4.3.5.1, win32, Ita gui and local help; - Adobe Acrobat Reader XI, 11.0.09, win32. Have All a nice weekend, Carlo -- To unsubscribe e-mail to: users+unsubscr...@global.libreoffice.org 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 -- To unsubscribe e-mail to: users+unsubscr...@global.libreoffice.org 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
Re: [libreoffice-users] PDF export checking whether the file is locked (opened) by another program before starting exporting over it
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: users+unsubscr...@global.libreoffice.org 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
