Joined: Jun 21, 2003 Posts: 173 Location: Selmer, Tennessee
Posted: Sat Jul 10, 2010 9:51 am Post subject: Don't leave Neo running overnight!
My system is 10.6.4, running Neo 3.1.1. p 1.
I was working on a 24-page document. Left the machine in a sleep state overnight. Resumed work next morning. On attempt to save, got the dreaded general error warning. Since the parent file is on a different server on a peer-to-peer wireless network (Time Capsule), I tried saving to the desktop. Still got the General I/O error. Like a dummy, I quit the program without thinking to copy my new (unsaved) work into text edit, and I lost it all. My fault.
So last night, I again left the machine in a sleep state with Neo still active. I typed a couple of sentences and tried to save: General I/O error!
During these IO errors, you loose all your pictures; the frames where the pictures should appear display various portions of the document text. The Backup files in /Preferences/NeoOffice-3.0/.../backup all changed from .bak extensions to .odt extensions and all were blank. (All but one: that one was the old backup that was written before the sleep state.) Pretty weird.
I don't think this is anything Patrick can fix. I haven't tried it with OpenOffice or GoOOo, but when you start talking about system i/o, that doesn't sound like something Neo would have much to do with. Maybe the OOo code base, but not the Neo mods. I have noticed too that the longer you let Neo run before quitting, the longer it takes to shut down. Memory leaks in the base code? I dunno. But it ain't good.
So don't leave critical work on the machine overnight. Save and quit Neo when you're done. Restart is pretty quick on Snow Leopard, so it shouldn't slow you down much. And don't join my dummy club: If it does quit saving on you, you can always copy your work to a TextEdit document before you quit. _________________ Jim Plante
MacOS X 10.6.34, MacBook 2GHz C2Duo, 2gb, Neo 3.1.1 p 1
Posted: Sat Jul 10, 2010 10:31 am Post subject: Re: Don't leave Neo running overnight!
Jim wrote:
I was working on a 24-page document. Left the machine in a sleep state overnight. Resumed work next morning. On attempt to save, got the dreaded general error warning. Since the parent file is on a different server on a peer-to-peer wireless network (Time Capsule), I tried saving to the desktop. Still got the General I/O error. Like a dummy, I quit the program without thinking to copy my new (unsaved) work into text edit, and I lost it all. My fault.
I cannot reproduce this problem. I had NeoOffice open all night last night and my machine was fully asleep for at least 12 hours and I experienced no problems saving.
I think that the key piece of data here is that the file you are editing is on a remote volume and that volume is getting unmounted. Once that volume goes away, NeoOffice's underlying OpenOffice.org code appears to get very confused because it can no longer find the file that it was editing.
In your case, there might still be hope in your situation but only if you still have your unsaved document open. After you encounter the General I/O error, can you remount the remote volume and then try saving again? Does NeoOffice still not allow you to save after the remote volume has become accessible again.
Jim wrote:
...The Backup files in /Preferences/NeoOffice-3.0/.../backup all changed from .bak extensions to .odt extensions and all were blank. (All but one: that one was the old backup that was written before the sleep state.) Pretty weird.
That makes sense. After all, once you put your machine to sleep, you are stopping the CPU from running so all applications are halted until you unsleep your machine. An application like NeoOffice cannot do work (like making backups) when the machine has halted itself.
Joined: Jun 21, 2003 Posts: 173 Location: Selmer, Tennessee
Posted: Sat Jul 10, 2010 10:42 am Post subject:
Quote:
I think that the key piece of data here is that the file you are editing is on a remote volume and that volume is getting unmounted.
Yep. It got unmounted again this morning for some reason, too. Only I outfoxed it this time, and copied the new stuff to TextEdit and then copied it back into the re-opened document.
N.B.: Remounting the unmounted volume doesn't do anything to ameliorate the condition. Once Neo becomes confused, it's like arguing with a menopausal woman: You ain't gonna win.
What's puzzling is that it won't let you "save as" to the primary HDD either.
Quote:
Jim wrote:
Quote:
...The Backup files in /Preferences/NeoOffice-3.0/.../backup all changed from .bak extensions to .odt extensions and all were blank. (All but one: that one was the old backup that was written before the sleep state.) Pretty weird.
That makes sense. After all, once you put your machine to sleep, you are stopping the CPU from running so all applications are halted until you unsleep your machine.
Actually, the .odt backups were made after the machine was awakened, if the time stamp means anything. IOW, it quit making .bak's and started saving blank .odt's after it became confused.
I think we can put this one to bed, except for puzzling about how a server becoming unmounted confuses the program. Seems to me that OOo handles this poorly, but I doubt you can do anything about it. I wanted to warn fellow users about this, and give them a workaround to prevent lost work. _________________ Jim Plante
MacOS X 10.6.34, MacBook 2GHz C2Duo, 2gb, Neo 3.1.1 p 1
Actually, the .odt backups were made after the machine was awakened, if the time stamp means anything. IOW, it quit making .bak's and started saving blank .odt's after it became confused.
I now understand: backup saves are affected by the same save error.
Jim wrote:
I think we can put this one to bed, except for puzzling about how a server becoming unmounted confuses the program. Seems to me that OOo handles this poorly, but I doubt you can do anything about it. I wanted to warn fellow users about this, and give them a workaround to prevent lost work.
I think there still is one possible workaround: open a new empty document in NeoOffice, go back to the document that you cannot save and select all content by selecting the Edit :: Select All menu, and then pasting the content into the new empty document.
This is similar to copying to TextEdit, but you can lose formatting data when copying your document back and forth between different applications. Since the new empty document does not have a file open on the remote volume that unmounted, you should be able to save the new document that you copied your content into with no loss of formatting data.
Joined: Jun 21, 2003 Posts: 173 Location: Selmer, Tennessee
Posted: Sat Jul 10, 2010 11:03 am Post subject:
Copying to a new doc might work OK, but once Neo gets confused, I don't trust it. It gets to act goofy exactly once, and I'm going to save and restart it before doing anything else.
In this case, all I'm losing is a bunch of text, so reformatting is easy: I use styles a *lot*, so just selecting the text and clicking a style is usually all that's necessary. That paint-bucket style tool works well, too. The most I'm concerned with is a page or three of text, and not much in the way of formatting. Takes at most a minute or two.
And I should note that the copy of the document originally saved on the remote server remains untouched, so all I have to do is add back the lost text, and I'm back in business.
Anyway, thanks for your interest and your responses, Patrick. Neo is still the only real competitor for MS Word. And at least when Neo goes crazy, you can usually recover your content. Word will mangle it. (Maybe the new XML format is better; I'll let somebody else find out, though.) _________________ Jim Plante
MacOS X 10.6.34, MacBook 2GHz C2Duo, 2gb, Neo 3.1.1 p 1
Joined: Jun 21, 2003 Posts: 173 Location: Selmer, Tennessee
Posted: Sat Jul 10, 2010 11:09 am Post subject:
One more thing just crossed my mind. In these "unmounted server" situations, Neo loses track of imbedded .png's as well. The photo frames contain text grabbed from indeterminate points within the document. So select all-copy-paste might not be what you want to do if you have lots of graphics included.
Why it would lose imbedded pictures is beyond me, but it does. I could understand it if those pix were linked, but they're not. Looks like something seriously screws with a stack of pointers when this happens. _________________ Jim Plante
MacOS X 10.6.34, MacBook 2GHz C2Duo, 2gb, Neo 3.1.1 p 1
Why it would lose imbedded pictures is beyond me, but it does. I could understand it if those pix were linked, but they're not. Looks like something seriously screws with a stack of pointers when this happens.
Are you sure that the images are not linked? If they are linked to another file on the same unmounted remote volume, that would probably explain why your images also become unreadable.
To check if your images are linked instead of embedded, right-click or Control-click on an image. In the popup menu that appears, select the Picture menu. In the dialog that appears, click on the Picture tab.
If your graphic is truly embedded in your document, the "File name" field in the "Link" section will be set to "[None]". However, if you see a path in that field, then your image is linked to a separate image file.
Joined: Jun 21, 2003 Posts: 173 Location: Selmer, Tennessee
Posted: Sun Jul 11, 2010 4:34 am Post subject:
They're not linked. I just rechecked to be sure.
The document is a narrative appraisal report on residential property, so it has lots of pictures and graphs. When finished (about 35-40 pages or so), it will be exported to .pdf for delivery to the client. I got into the habit of embedding graphics 'way back in a version of Neo that had some trouble with linked graphics. Since HDD storage is cheaper than beer, I just never saw any need to change to links again. _________________ Jim Plante
MacOS X 10.6.34, MacBook 2GHz C2Duo, 2gb, Neo 3.1.1 p 1
I now know what is happening. It does not matter if the images are embedded or linked for the remote volume unmounting to cause what you are seeing.
What is happening is that both NeoOffice and OpenOffice.org do "lazy loading" of images in your document. Lazy loading means that the code will not read the image bits in your file until the first time that the image needs to be displayed.
So, if you open your document and do not scroll through all of the pages and then the remote volume unmounts, copying the entire document will be the force NeoOffice to try to load all of the unloaded images. Since the unloaded embedded images are in the same file that you cannot access any longer, loading the images fail and, as you saw, copying many of the images fails.
I know that does not help, but I hope that at least explains what is going on.
Joined: Jun 21, 2003 Posts: 173 Location: Selmer, Tennessee
Posted: Mon Jul 12, 2010 5:13 am Post subject:
Thanks, Patrick. It's good to know how the program works. That'll help me resolve problems in the future, too. _________________ Jim Plante
MacOS X 10.6.34, MacBook 2GHz C2Duo, 2gb, Neo 3.1.1 p 1
Joined: Jun 21, 2003 Posts: 173 Location: Selmer, Tennessee
Posted: Wed Jul 14, 2010 4:50 am Post subject:
I found the reason for Neo losing its server link, so I thought a follow-up would be appropriate. It happened again yesterday.
As Patrick pointed out, when the remote server becomes unmounted, Neo loses its link to the file(s). What can cause this? One of the machines is a laptop, the other is an iMac running on an uninterruptible power supply. So why would a server become unmounted?
Here's one way that I didn't think about: The Time Capsule on my network runs in bridge mode, passing network traffic through a router and to the cable modem and printer. Neither of these two is on a UPS, so when the power flicks off, even briefly, the Time Capsule flicks off too. The server becomes unmounted. Once Neo loses its hold on the hand rail, it is forever lost. That open document cannot be saved, period. You can't even save it to the local HDD. It recognizes that it doesn't know what it's talking about, and will not save a doc it isn't sure of. (Wish people were like that.)
So when it failed yesterday, I went to the Finder, re-mounted the server, and duplicated the affected file. I opened the duplicate in Neo, and found that I hadn't been saving as frequently as I thought: about six pages were lost. I simply copied the new stuff from the bad document into the duplicate, and saved it. All the formatting stayed put; the graphics moved around a little, but I was able to recover the new work in about 10 minutes.
Thanks again, Patrick, for your help in understanding this problem. _________________ Jim Plante
MacOS X 10.6.34, MacBook 2GHz C2Duo, 2gb, Neo 3.1.1 p 1
Once Neo loses its hold on the hand rail, it is forever lost. That open document cannot be saved, period. You can't even save it to the local HDD.
If it hasn't already been filed, that's probably worth filing as an issue with OOo. Not being able to "Save As" a document in memory to a different volume when the origin volume is gone seems like a massive dataloss bug. Even if they are concerned that the copy in memory might be missing something, letting you save it with a warning that some content may be lost since the original volume has disappeared is a better situation than the current one.
Smokey _________________ "[...] whether the duck drinks hot chocolate or coffee is irrelevant." -- ovvldc and sardisson in the NeoWiki
I don't know if it is feasible or not, but I have some ideas that could potentially protect people from this problem. We know that the problem is that putting Mac OS X in sleep causes a remote volume to be unmounted.
While we cannot prevent Mac OS X remote volumes from unmounting, NeoOffice does get notified when you try to sleep your Mac OS X. Potentially, following could be done whenever NeoOffice gets such a notification: not let Mac OS X go to sleep.
NeoOffice can request but not force Mac OS X to delay sleeping so it may be feasible to detect if NeoOffice has any files on a remote volume open and, if so, repeatedly request that sleeping be delayed until either the remote files are no longer open or Mac OS X ignores NeoOffice's request and forcefully goes to sleep.
NeoOffice can request but not force Mac OS X to delay sleeping so it may be feasible to detect if NeoOffice has any files on a remote volume open and, if so, repeatedly request that sleeping be delayed until either the remote files are no longer open or Mac OS X ignores NeoOffice's request and forcefully goes to sleep.
Can you also display an alert when this process starts so that the user will have some idea why their Mac is not sleeping/NeoOffice is preventing their Mac from sleeping?
Preventing dataloss is very important, but just like people had no idea what was causing dataloss, people will have no idea what's preventing their Macs from sleeping (not sleeping is also annoying, though obviously less so than dataloss), and showing an alert will at least notify people in the morning what happened (whether NeoOffice is able to prevent sleep all night or Mac OS X finally ignores NeoOffice and sleeps anyway).
Smokey _________________ "[...] whether the duck drinks hot chocolate or coffee is irrelevant." -- ovvldc and sardisson in the NeoWiki
Preventing dataloss is very important, but just like people had no idea what was causing dataloss, people will have no idea what's preventing their Macs from sleeping (not sleeping is also annoying, though obviously less so than dataloss), and showing an alert will at least notify people in the morning what happened (whether NeoOffice is able to prevent sleep all night or Mac OS X finally ignores NeoOffice and sleeps anyway).
I might be able to do that. Although I would need translations for the dialog text. If we can do this, here is what I think would happen:
1. The sleep handler would iterate through each of the open documents and see if the document resides on a remote volume
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
The question is what to put in that dialog. Here is my proposed text:
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 disconnect your connection to the remote volume causing loss of data or the inability to save your document.
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
