Accidentally, i was hooking up on another wireless network yesterday and was surprised to see that the problem was gone while connected in that particular network.
I have absolutely no idea what the difference was - but the point is that exactly the same configuration seem to work in some networks and not on others.
Could it be a DNS issue? Or that some ports need to be open in order for OO to open/save properly? Either way, OO is doing something that it should not, that's for sure.
Last edited by SwedishWings; June 19th, 2010 at 07:11 AM.
Does anyone have an account on www.OpenOffice.org?
Should I send an e-mail to them and report the bug?
I created an accout. I am just waiting for an email that will verify my login details.
I did have a look at the Issue Tracker. Someone did mention something about slow saving and loading times, and did mention that it may be a problem that is related to his network printer. But his issue is on Windows XP and I did not check which version of OpenOffice it was. I will get back to you on that one.
No one has mentioned any issue on Ubuntu about slow loading or saving times. But I will search a bit more.
I have sent in an issue report. Hopefully they will get back to me soon.
Are there perhaps any Ubuntu 9.10 users who installed OpenOffice 3.2.0 or 3.2.1 and experienced the same bug?
Here is the report on the OpenOffice.org site:
Tombgeek, thanks for helping out!
So they have gotten back to me (as you can see in the link). It seems they have been able to discover the issue. However, due to the fact I am not too experienced with programming (I only know the basics of Delphi and Pascal, and I don't even know how to do loops and string handling), I have absolutly do idea whatsoever of what this guy is talking about. Perhaps you guys know. His username is "hdu":
Then he placed an attachment:Confirming on Debian for doing the file open dialog. Adjusting the priority as the multisecond hang is
quite bad. Profiling shows that the culprit seems to be the excessive use of "realpath()" on EACH file of the
- is that level of detail needed when the file name alone should suffice to fill the open/close dialogs?
- why on each file in the directory?
#1 ___lxstat64 (vers=3, name=0xfffba140 "/net/hs-eham02-01", buf=0xfffba09c) at sysdeps/unix/sysv/linux/lxstat64.c:48
#2 __realpath (name=0xee6d60f4 "/home/hd114770/tmp/tausch", resolved=0xfffba140 "/net/somehost") at canonicalize.c:162
#3 ?? () libuno_sal.so.3
#4 ?? () from libuno_sal.so.3
#5 osl_getFileStatus () from libuno_sal.so.3
#6 osl::DirectoryItem::getFileStatus(osl::FileStatus& ) () from libucpfile1.so
#7 fileaccess::shell::getv(fileaccess::Notifier*, com::sun::star::uno::Sequence<com::sun::star::bean s::Property> const&, osl::DirectoryItem&, rtl::OUString&, unsigned char&) () from libucpfile1.so
#8 fileaccess::XResultSet_impl::OneMore() () from libucpfile1.so
#9 fileaccess::XResultSet_impl::next() () from libucpfile1.so
#10 svt::FileViewContentEnumerator::enumerateFolderCon tent() () from libsvtli.so
#11 svt::FileViewContentEnumerator::enumerateFolderCon tentSync(svt::FolderDescriptor const&, IUrlFilter const*, com::sun::star::uno::Sequence<rtl::OUString> const&) () from libsvtli.so
#12 SvtFileView_Impl::GetFolderContent_Impl(svt::Folde rDescriptor const&, FileViewAsyncAction const*, com::sun::star::uno::Sequence<rtl::OUString> const&) () from libsvtli.so
#13 SvtFileView_Impl::GetFolderContent_Impl(String const&, FileViewAsyncAction const*, com::sun::star::uno::Sequence<rtl::OUString> const&) () from libsvtli.so
#14 SvtFileView::ExecuteFilter(String const&, FileViewAsyncAction const*) () from libsvtli.so
#15 SvtFileView::Initialize(String const&, String const&, FileViewAsyncAction const*, com::sun::star::uno::Sequence<rtl::OUString> const&) ()