Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | OpenOffice cannot be launched from MFS partition | ||
---|---|---|---|
Product: | porting | Reporter: | Unknown <non-migrated> |
Component: | code | Assignee: | AOO issues mailing list <issues> |
Status: | REOPENED --- | QA Contact: | |
Severity: | Trivial | ||
Priority: | P2 | CC: | issues |
Version: | OOo 1.0.0 | ||
Target Milestone: | AOO Later | ||
Hardware: | PC | ||
OS: | Linux, all | ||
Issue Type: | DEFECT | Latest Confirmation in: | --- |
Developer Difficulty: | --- |
Description
Unknown
2002-05-15 13:57:48 UTC
TM->FT: I think this one is more a request for a feature or an enhancement than a bug. Please have a look at it. Thanks ! Can you please give good reasons why we should put resources in this IMO rather scarce problem? Thx. Well, this makes open office not usable on MFS. And that means that there's no suitable technology for SSI-like linux system based on cluster of linux workstations as major (only) office software will not work on this system. The only solution of this problem without modification of Open Office code I can see is usage of NFS for homespace and this will run slower. I'm afraid I cannot give better reason then this. Any way if you will decide that this problem is not worth you effort, why not put into documentation/release notes that Open Office is not MFS compatible? Hi Evgeniy, Well, at least I haven't ever heard of a MFS filesystem, and probably others as well. That might be the reason why it's not mentioned at all. But back to the facts. The reason why this happens at all, is that the 'fs_type' returned by 'statfs()' is not recognized as a 'remote' file- system like NFS. In case it would have been recognized as such, the code involved would have switched back to 'read()' / 'write()' system calls instead of 'mmap()'. I have no proper solution for now, but I'll take this issue. And thanks for the detailed diagnose, that saves the debugging stage for me. Matthias Reassigning to myself. Module 'ucb/store' doesn't recognize MFS (MOSIX File System) as remote. Look at 'fs_type' check in 'porting/sal/osl/unx/file.c', function 'osl_getVolumeInformation', which currently recognizes NFS and SMB as remote via their respective superblock magic numbers. Well, I've got the idea, nice that it can be corrected. Two ways, either I patch MFS statfs call to pretend to be NFS, but this is potentially dangerous. So better to patch Office code, the magic number for MFS is: statfs.f_type=235466776 Meanwhile I can try to set the same handling as for NFS in 'porting/sal/osl/unx/file.c', function 'osl_getVolumeInformation' and test it. Silly question, where do I get the sources of the stable 1.0.0 release? I don't want to deal with snapshots as there can be other buggies :@) Evgeniy Hi Evgeniy, Thanks for the 'magic' number. Silly, or not, a link to download the source is in the left navbar on the main web page: Downloads - Application / Source / Developer. If you haven't compiled the source before, you probably need to be warned that OpenOffice.org is quite large. But you only need to build up to the 'sal' project, which happens to one of the lowest level modules. Good luck, Matthias Hi Hennes, Reassigning to you, as discussed. Should go into OOo 1.0.1, if possible. Thanks, Matthias Accepted. Added magic number for Mosix file system to /sal/osl/unx/file.c Revision 1.51.2.8. Committed to branch OOO_STABLE_1. Hi, The bug is still there in 1.0.1 though there is some code in source in file.c to handle MFS, If I install a binary, I still get the same crush. ?? Regards Evgeniy removed keyword "ooo1.0" in favour of a target milestone "OOo 1.0.2". Don't have further informations needed to fix the bug. . is this still an issue ? mav: Please take over. . Reset assigne to the default "issues@openoffice.apache.org". |