<html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> Hi On windows you could lookup the environment variable COMPUTERNAME and put that in the lock file. That would solve the issue with flaky remote shares. Could use uname on linux/MacOS. We could also use the IP address of the machine - that should help with flaky NFS shares. Although in the presence of DHCP, it can be hard to figure out who the problem machine was. For bonus points, put all of these in the lock file: (1) Some kind of COMPUTERNAME/uname lookup (2) IP address (3) MAC address That should be fast and safe, but necessarily as user-friendly as the current solution. For extra-extra bonus points, we could run the DNS resolution on a separate thread and also store that in the lock file if it is available when we create the lock file :-) Regards, Noel Grandin. Michael Stahl wrote: <blockquote cite="mid:j9r1tv$ft8$1@dough.gmane.org" type="cite">On 14/11/11 12:30, Michael Meeks wrote: <blockquote type="cite"> On Sun, 2011-11-13 at 12:06 +0200, Tor Lillqvist wrote: <blockquote type="cite">But in general we should avoid potentially pointless DNS calls. Let's not risk having to wait for DNS timeouts in badly configured situations. I think there has been bug reports of OOo and/or LO being very slow to start in some cases, where the root cause has been some DNS call timing out? </blockquote>     Yes - I've seen this. I spent a while debugging the:     "OO.o takes 14 seconds to start instead of 10"     type bugs, which used to riddle the whole linux desktop in this situation, and that I spent time in a previous life fixing / working around. If, as Stephan suggests, we use this for .lock files - then I don't believe we should ;-) having a potential 10+ second delay before opening a file is not ideal. [ and the duplicate count for these huge login / startup delays was really quite real&  included me FWIW ]. </blockquote> hmm... but this is written in the lock file for a reason, so that people who edit files on NFS shares can figure out where the office process that is preventing them from editing is running. perhaps it would be possible to do the DNS lookup asynchronously, so it does not block the user experience? <blockquote type="cite">    Indeed, it'd be rather nice if we could sort out our .lock files story so that I don't routinely see bogus/broken / stale lock file dialogs but ... ;-) that's a different story I guess; and one that needs some unit tests I suppose. </blockquote> please note that the file locking implementation is very brittle because it has to work on any number of randomly broken networking filesystem setups; changing anything there is a huge time sink with high regression risk (at least that's what i remember from my former colleague). _______________________________________________ LibreOffice mailing list <a class="moz-txt-link-abbreviated" href="mailto:LibreOffice@lists.freedesktop.org">LibreOffice@lists.freedesktop.org</a> <a class="moz-txt-link-freetext" href="http://lists.freedesktop.org/mailman/listinfo/libreoffice">http://lists.freedesktop.org/mailman/listinfo/libreoffice</a> </blockquote> <hr>Disclaimer: <a href="http://www.peralex.com/disclaimer.html">http://www.peralex.com/disclaimer.html</a> </body> </html>