2. When the first document that resides on a remote volume, NeoOffice brings that document to the front, displays a dialog, and requests Mac OS X defer sleeping
What happens if there are n>1 documents on remote volumes?
If the first document is successfully closed (i.e., the user is present at sleep time), will each additional document on a remote volume also prompt?
And if the user is not there to act on the alert, that alert will remain (either stopping sleep successfully, or as an after-the-fact note if Mac OS X ignores NeoOffice's request not to sleep and sleeps anyway)?
pluby wrote:
The question is what to put in that dialog. Here is my proposed text:
Looks good in general, but I'd change the second paragraph to say
Quote:
This document resides on a remote volume and sleeping your computer will terminate your connection to the remote volume, causing loss of data or the inability to save your document.
may->will: because sleeping will end the connection to the remote volume
disconnect->terminate: just so there aren't two "connect"-based words
added comma: it's a dependent clause (and, regardless, the comma improves readability)
Smokey _________________ "[...] whether the duck drinks hot chocolate or coffee is irrelevant." -- ovvldc and sardisson in the NeoWiki
What happens if there are n>1 documents on remote volumes?
If the first document is successfully closed (i.e., the user is present at sleep time), will each additional document on a remote volume also prompt?
I think you are wrongly assuming that NeoOffice can block the sleep indefinitely while it is waiting for the user to respond to the dialog. That is not how the sleep notifications work in Mac OS X.
Essentially what happens is that you are supposed to respond very quickly to such notifications with either an "OK to sleep" or "please delay" response. Not responding quickly is likely to be interpreted as an "OK to sleep" response so what I would do is give a "please delay" response and then display the dialog.
The "please delay" usually buys you 30 seconds and then Mac OS X sends another notification. So while I will likely sequentially display a dialog for each document, if there are several documents or the user does not respond to the dialog, there will be a dialog showing when the Mac OS X sends the next sleep notification. In that case, again we give a "please delay" response and let the the current iteration continue until the user has gotten through each remote document that is open.
sardisson wrote:
And if the user is not there to act on the alert, that alert will remain (either stopping sleep successfully, or as an after-the-fact note if Mac OS X ignores NeoOffice's request not to sleep and sleeps anyway)?
Yes, the alert should remain.
sardisson wrote:
Looks good in general, but I'd change the second paragraph to say
Quote:
This document resides on a remote volume and sleeping your computer will terminate your connection to the remote volume, causing loss of data or the inability to save your document.
may->will: because sleeping will end the connection to the remote volume
disconnect->terminate: just so there aren't two "connect"-based words
added comma: it's a dependent clause (and, regardless, the comma improves readability)
I will use your wording except that "will terminate" should be "may terminate" as many remote file system protocols do support sessions and can handle network interruptions. What is likely happening in the cases that we have seen is that the remote servers are configured to terminate the session after some period of time of inactivity similar to how many web applications forcefully log you out after a preset amount of time.
In other words, if you sleep for only a few minutes, everything may be OK and no damage is done. But the longer you sleep your computer, the greater likelihood that you will see termination of your connection to the remote volume.
So, given Smokey's wording changes, here is what I will put in the dialog:
Quote:
Please save any changes and close this document before putting your computer to sleep.
This document resides on a remote volume and sleeping your computer may terminate your connection to the remote volume, causing loss of data or the inability to save your document.
The dialog will then have the "Close Document" and "Cancel" buttons (these buttons already have localizations in OpenOffice.org and do not need to translated).
Joined: Jun 21, 2003 Posts: 173 Location: Selmer, Tennessee
Posted: Sun Aug 08, 2010 12:32 am Post subject:
Patrick, instead of the dialog, why not just automatically save the open docs to the desktop and close them? Or, better yet, save them as the dash-1 version in the original remote folder, e.g., "MyFile.odt" -> "Myfile-1.odt". You'd have to update the Recent Files list, too.
The returning user would see that his 854-page doc is missing, and flat out panic. The first time it happened, he'd search for his file, find the original and the dash-1, puzzle about whattinhell is the MyFile-1 stuff, open it, and find that his problem is solved. He could save-as back to his original file.
This would create transient user panic, but no data would be lost. He would then post here without searching, and could have his wounds tended.
N.B., using this solution, you should *not* save to the original file; the user may have made changes to the doc that he does not want to save into the original. _________________ Jim Plante
MacOS X 10.6.34, MacBook 2GHz C2Duo, 2gb, Neo 3.1.1 p 1
Patrick, instead of the dialog, why not just automatically save the open docs to the desktop and close them? Or, better yet, save them as the dash-1 version in the original remote folder, e.g., "MyFile.odt" -> "Myfile-1.odt". You'd have to update the Recent Files list, too.
Sorry, but I do not agree with this approach and, more importantly, it is a huge increase in work to implement. Why I don't agree with this approach is that ultimately this is not a NeoOffice problem. Instead, it is a combination of two things:
1. A remote file server that is configured to timeout too quickly.
2. Users don't realize they are using a flaky network resource and expect that resource to remain connected even after their machine is put to sleep for hours
Frankly, the first issue is not ours. It belongs to whomever administers your remote file server. I understand that it is easier to post to our forum, but but the real solution is to get your remote file server's administrator to increase the connection timeout to match the likely sleep time. Most administrators use the default settings when setting up an AFP or SAMBA file server.
Given that the second issue is caused by the first issue (I don't expect NeoOffice users to know how their remote file server has been configured), I believe that I can mitigate some of first issue by warning and educating users of the possible problem that they might see and then they can take appropriate action.
Essentially, you are proposing that NeoOffice take over entire responsibility for your remote server's flakiness. But the real problem is that your IT staff has given you a flaky network resource so the real solution is for users like yourself to work with your IT staff to either setup a more fault-tolerant network resource or avoid using the flaky resource.
I am happy to add code that warns of what may happen so that users understand that they are using a flaky resource, but I am not going to implement code that relies on a guess of how people will find some backup copy that is made after silently dropping files somewhere on their machine. Again, the problem is the flaky network resource and users need to work that problem out within their own organizations.
I will use your wording except that "will terminate" should be "may terminate" as many remote file system protocols do support sessions and can handle network interruptions. What is likely happening in the cases that we have seen is that the remote servers are configured to terminate the session after some period of time of inactivity similar to how many web applications forcefully log you out after a preset amount of time.
Ah, I wasn't aware that there actually were some cases/servers where sleep was "survivable".
Everything sounds good to me, then.
Smokey _________________ "[...] whether the duck drinks hot chocolate or coffee is irrelevant." -- ovvldc and sardisson in the NeoWiki
I did some experimentation to see if my proposal will actually work. Unfortunately, I have bad news: there is no way to delay sleeping when the user closes their notebook or selects the Apple :: Sleep menu. The only time that we can delay sleeping is when Mac OS X puts the machine to sleep due to inactivity.
Realistically, this limits our options as showing a dialog that the user will not see until after they reawaken their machine does not help the user avoid the problem with being connected to a flaky network so clearly a different approach is needed.
As I mentioned in previous posts, the problem is that we cannot directly control the behavior of a remote volume. The remote machine can get disconnected for a variety of reasons ranging from inactivity timeouts to network connectivity failures.
So what options are left? Only one option I think is available: keep "touching" the any open remote files every couple minutes. By doing this, Mac OS X will try to send a query to the machine where the remote volume resides and, hopefully, that query will prevent the remote volume from disconnecting your Mac due to inactivity.
Note also that this periodic query will also prevent your Mac from automatically going to sleep when inactive. It will not prevent you from forcefully putting it to sleep by closing your laptop or selecting the Apple :: Sleep menu.
Nothing will change for users who have only local files open. Under my new proposal, the periodic query code will kick in silently and only when you have files on remote volumes open.
I will try to get the code implemented in the next few days. When I have the code ready, I will post a test patch for you to try.
So what options are left? Only one option I think is available: keep "touching" the any open remote files every couple minutes. By doing this, Mac OS X will try to send a query to the machine where the remote volume resides and, hopefully, that query will prevent the remote volume from disconnecting your Mac due to inactivity.
While looking at the code to figure out how to implement my new proposal, I realized that, in theory, I might have an additional approach that can enhance the effectiveness of the first approach: if the remote volume is remounted I might be able to silently reestablish a connection to the files on the remote volume so that the OpenOffice.org application code does not find an error.
But before I try to implement this approach, I would like to know if remounting the unmounted remote volume will have the same path or not. So, can you try the following:
1. In the Finder, right-click or Control-click on one of your large .odt files on your remote volume and in the popup that appears, select the Get Info option. In the Window that appears, copy what appears in the General :: Where field.
2. Put your machine to sleep for enough time that the remote volume will unmount. When you wake up your machine, verify that the remote volume is no longer accessible and remount it. Then perform step 1 again and get the General :: Where field for the same .odt file.
3. Post the General :: Where field values from steps 1 and 2. Hopefully, they are identical because if they are identical, then my "add-on" approach might have a chance of working.
I have some good news: I found a reproducible test case for the "lost images after saving" behavior. I can reproduce it running the test case with a file on my local hard drive so the lost images bug is unrelated the "cannot save to remote volume that has been unmounted and remounted" problem.
Since the reproducible test case is in OpenOffice.org issue 108035 and is easily reproducible on my machines and that was the bug that started this thread, I am going to shift my attention to fixing the lost images bug.
In the meantime, there is a workaround: turn off AutoRecovery. In the OpenOffice.org issue, the issue reporter has found that this bug occurs when an autorecovery save happens and then you save your document so can avoid this bug by turning off AutoRecovery.
To turn off AutoRecovery, select the Tools :: Options menu and in the dialog that appears, select the Load/Save :: General item, uncheck the "Save AutoRecovery information every" checkbox, and press the OK button.
When I find the cause of this OpenOffice.org bug and I am able to fix it, I will post a test patch for you to try.
Joined: Jul 05, 2005 Posts: 685 Location: North West England
Posted: Fri Aug 13, 2010 1:05 pm Post subject:
This looks very like an issue I encounter from time to time in a document which I an a Windows user both work on. She sometimes finds after a save images simply disappear. Sometimes I open files she has sent me and just have 'Read error' warnings in place of images - usually together with text from other parts of the same document. _________________ MacBook Pro
13-inch, Mid 2012
Processor 2.5 GHz Intel Core i5
Memory 4 GB 1600 MHz DDR3
Graphics Intel HD Graphics 4000 512 MB
OS X 10.9.3 (13D65)
This looks very like an issue I encounter from time to time in a document which I an a Windows user both work on. She sometimes finds after a save images simply disappear. Sometimes I open files she has sent me and just have 'Read error' warnings in place of images - usually together with text from other parts of the same document.
This problem is definitely in all versions of OpenOffice.org and OpenOffice.org forks like Go-oo and NeoOffice. What I don't understand is why they closed that issue as the bug is easily and repeatedly reproducible using the sample document and steps in that issue.
Joined: Jul 05, 2005 Posts: 685 Location: North West England
Posted: Fri Aug 13, 2010 1:21 pm Post subject:
Hmm. If (when) you find a fix for it, how likely is it that they will incorporate it into OOo? IT would be great to have it fixed for NO, but it would be better if it was fixed for Windows versions as well. _________________ MacBook Pro
13-inch, Mid 2012
Processor 2.5 GHz Intel Core i5
Memory 4 GB 1600 MHz DDR3
Graphics Intel HD Graphics 4000 512 MB
OS X 10.9.3 (13D65)
Hmm. If (when) you find a fix for it, how likely is it that they will incorporate it into OOo? IT would be great to have it fixed for NO, but it would be better if it was fixed for Windows versions as well.
We have gone over this in past but I will repeat it since it has been awhile: any changes that we make are freely available for use by Oracle or Novell or any other OpenOffice.org fork under the GPL. While Oracle (and previously Sun Microsystems) would want us to do the work and assign ownership without anything in return so that they can use our work in their proprietary, non-open source products like StarOffice, our code remains entirely under the GPL.
Joined: Jul 05, 2005 Posts: 685 Location: North West England
Posted: Fri Aug 13, 2010 10:35 pm Post subject:
Well hopefully, then, OOo will change the status from wontfix and incorporate any fix you can find. I hope they won't just ignore any fix you can make (which is really what I was getting at). _________________ MacBook Pro
13-inch, Mid 2012
Processor 2.5 GHz Intel Core i5
Memory 4 GB 1600 MHz DDR3
Graphics Intel HD Graphics 4000 512 MB
OS X 10.9.3 (13D65)
Well hopefully, then, OOo will change the status from wontfix and incorporate any fix you can find. I hope they won't just ignore any fix you can make (which is really what I was getting at).
You may not realize it, but you are essentially recommending that Oracle violate our GPL license. Last I checked, Oracle distributes StarOffice which is a proprietary application and incorporating GPL code into a proprietary, closed source product is a clear violation of the GPL.
Also, the OpenOffice.org code (which is the subset of the proprietary StarOffice code owned by Oracle) is LGPL to make it "proprietary friendly".
So why exactly would we use NeoOffice donations to subsidize the proprietary business activities of a Fortune 500 company and its partners?
All times are GMT - 7 Hours Goto page Previous1, 2, 3Next
Page 2 of 3
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You cannot download files in this forum
