View previous topic :: View next topic |
Author |
Message |
DB Pure-blooded Human
Joined: Sep 15, 2009 Posts: 36 Location: Providence, RI
|
Posted: Wed May 22, 2013 7:49 am Post subject: Interaction with Transmit |
|
I use Transmit to keep files that I use currently on Amazon S3. Transmit enables me to mount my Amazon account as a disk. If I try to save from NeoOffice to such a disk, it will always take a very long time and sometimes it fails. Using another approach I can open a file directly from the Transmit list and NeoOffice will save a revision of the file directly to Amazon S3 using this method. However the only way to copy a new file is to save to the computer and then move to S3 using Transmit. The odd thing is that OpenOffice handles these tasks without a hitch. It will save new files to S3 mounted as a disk as well as saving revised files. It also will load and save revised files to the Transmit list. I am wondering what difference in the two programs produces this result. |
|
Back to top |
|
|
pluby The Architect
Joined: Jun 16, 2003 Posts: 11949
|
Posted: Wed May 22, 2013 8:34 am Post subject: |
|
NeoOffice supports the following 2 Mac OS X features that neither OpenOffice nor LibreOffice support:
1. Native file locking
2. Versions
Native file locking is an advanced file system feature that allows multiple users to access the same file at the same time from a remote volume and all such users except one are given "read-only" access to the file to ensure that only one person at a time can save changes to a shared file.
Mac OS X Versions adds additional steps when saving a file in addition. The exact steps are not documented by Apple, but from my experience Mac OS X copies the existing file to a hidden folder on the same volume as the file before allowing NeoOffice's normal saving process to proceed. Then, NeoOffice saves to a temporary file on your machine and Mac OS X moves that temporary file to the file that you are saving to.
I do not know whether one or both of the above is not supported by the Transmit file system driver software, but as I mentioned the last time you posted about the Transmit file system, NeoOffice uses standard Mac OS X functions for native file locking and Versions so I suspect that there are bugs or missing file system features in the Transmit driver software.
Patrick |
|
Back to top |
|
|
pluby The Architect
Joined: Jun 16, 2003 Posts: 11949
|
Posted: Wed May 22, 2013 10:13 am Post subject: |
|
I forgot to add that I am interested to see which specific Mac OS X function the Transmit driver software is not handling properly.
To see that, can you do obtain a sample of the NeoOffice process the next time you see abnormal slowness in opening or saving a file? You can obtain a sample using the steps in this NeoWiki article.
Once you have obtained a sample of the NeoOffice process, please post a reply and attach the sample file to your post.
Patrick |
|
Back to top |
|
|
DB Pure-blooded Human
Joined: Sep 15, 2009 Posts: 36 Location: Providence, RI
|
Posted: Thu May 23, 2013 5:38 am Post subject: |
|
Hi Patrick,
As I said in my previous post, I may be the only person in the world trying to use NeoOffice in this way, so I appreciate your attention. It is also an indication of the excellence of your work that this is about all I can find to complain about although I use NeoOffice virtually every day and on several different machines and OS versions. (This is my MacBook Air running 10.8.6. I also use a Mini and a Mac Pro running Snow Leopard and a Power Mac G5 running NeoOffice 3.1.2 on Leopard 10.5.8.) In all these contexts NeoOffice works flawlessly. I am pleased to be able to contribute a bit to your project.
The Transit issue occurs in all of my permutations with some variations.
This morning in preparing the sample attached I noticed an interesting quirk. I opened a test file on S3, changed it, and saved it OK. The hangup occurs if I then try to save it again without change.
Thanks for your attention.
Richard Olmsted |
|
Back to top |
|
|
pluby The Architect
Joined: Jun 16, 2003 Posts: 11949
|
Posted: Thu May 23, 2013 7:47 am Post subject: |
|
DB wrote: | This morning in preparing the sample attached I noticed an interesting quirk. I opened a test file on S3, changed it, and saved it OK. The hangup occurs if I then try to save it again without change. |
One question: after you took the sample that you attached, did the save eventually finish? If not, did you have to force quit NeoOffice?
Patrick |
|
Back to top |
|
|
DB Pure-blooded Human
Joined: Sep 15, 2009 Posts: 36 Location: Providence, RI
|
Posted: Thu May 23, 2013 10:27 am Post subject: |
|
The file is finally written and NeoOffice returns to normal. It usually happens in a couple of minutes. However, sometimes it goes on so long that I give up and force close the program. |
|
Back to top |
|
|
DB Pure-blooded Human
Joined: Sep 15, 2009 Posts: 36 Location: Providence, RI
|
Posted: Thu May 23, 2013 10:29 am Post subject: |
|
I didn't really answer your question. Yes, this morning it finally returned to normal. |
|
Back to top |
|
|
pluby The Architect
Joined: Jun 16, 2003 Posts: 11949
|
Posted: Thu May 23, 2013 11:08 am Post subject: |
|
I looked at the sample file that you posted and the sample indicates that NeoOffice was spending most of its processing time in Mac OS X's "write" function. The Mac OS X write function appends bytes onto a file so I added some debug messages to NeoOffice's underlying OpenOffice.org code to see how many bytes are written with each write call.
What I found was that when I saved a 20 page .odt file, the OpenOffice.org code was writing only 2 or 4 bytes at a time and it would take hundreds or even thousands of write calls to save the whole file.
Writing such small chunks seems odd to me so one possibility is that a flood of small sized writes is overwhelming the Transmit driver software. So, to test if this is what is happening, in the following test patch I modified the OpenOffice.org code to write the document bytes to a temporary file and push the temporary file's bytes to the file you are saving to. Adding this intermediate "write to temporary file" step should cause the OpenOffice.org code to write much larger 32K byte chunks.
Can you install the following test patch and tell us if you still see abnormally slow saving to files on your Transmit volume?:
Intel:
http://juliette.neooffice.org/test/NeoOffice-3.3-Patch-6-Test-4-Intel.dmg
Patrick |
|
Back to top |
|
|
DB Pure-blooded Human
Joined: Sep 15, 2009 Posts: 36 Location: Providence, RI
|
Posted: Thu May 23, 2013 4:50 pm Post subject: |
|
I think you have fixed it! I have copied a 30,00O word document 96kb to a S3 directory at normal speed, a second or less. I have successfully overwrittn the original document with a revision and also using save as. It does not hang as it did before if you invoke the save function after a save and before any changes are made. I have loaded a document from the Transmit disk and saved it as PDF using the Export as PDF function. I have also loaded, revised, and saved a file from the Transmit listing (I was able to do that before.) I will play with it some more to see if there are any other problems. |
|
Back to top |
|
|
pluby The Architect
Joined: Jun 16, 2003 Posts: 11949
|
Posted: Thu May 23, 2013 5:05 pm Post subject: |
|
Can you also try the following?:
1. Use the File :: Save As menu and in the native save dialog that appears, change the "File type" to "Microsoft Word 97/2000/XP (.doc)"
2. Use the File :: Save As menu and in the native save dialog that appears, change the "File type" to "Microsoft Word 2007 XML (.docx)"
If abnormal slowness occurs in either of the above cases, that means that I need to duplicate my fix in different places within the OpenOffice.org code.
Patrick |
|
Back to top |
|
|
DB Pure-blooded Human
Joined: Sep 15, 2009 Posts: 36 Location: Providence, RI
|
Posted: Thu May 23, 2013 6:15 pm Post subject: |
|
I have successfully succeeded in saving the long document using Save As in both the .doc and .docx formats. doc takes a bit longer, no doubt because of its size, but otherwise normal. I tried it several times using each format with the same result. |
|
Back to top |
|
|
pluby The Architect
Joined: Jun 16, 2003 Posts: 11949
|
Posted: Thu May 23, 2013 6:50 pm Post subject: |
|
Since this fix works for you, I will include the fix in the next official NeoOffice patch that we release.
I think my fix is pretty low risk since the "save to temporary file" code was already there in the OpenOffice.org code. That code was just not being used for all saves and I merely made that code be used in all saves.
We will not put out the next official patch for at least a week so if you find an save failures or new cases of the abnormally slow saving, please let us know and post another sample.
Patrick |
|
Back to top |
|
|
DB Pure-blooded Human
Joined: Sep 15, 2009 Posts: 36 Location: Providence, RI
|
Posted: Thu May 23, 2013 7:04 pm Post subject: |
|
Thank you very much for this fix. It will simplify my life. And thanks again for your great program. I will let you know if I encounter any problems. |
|
Back to top |
|
|
pluby The Architect
Joined: Jun 16, 2003 Posts: 11949
|
Posted: Tue May 28, 2013 10:14 pm Post subject: |
|
FYI. I have included fix for the saving to a Transmit file bug in NeoOffice 3.3 Patch 7. The patch can be downloaded from the NeoOffice patch download page.
Patrick |
|
Back to top |
|
|
|