[framework-issues] [Issue 113207] OOo relies on temporary f iles existing after unlink
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=113207 --- Additional comments from thetrivialst...@openoffice.org Sat Oct 30 18:57:49 + 2010 --- This is a part of the POSIX spec that's difficult for network filesystems to do. NFS doesn't do it quite right either (it gets closer to the spec, but at the cost of doing some strange things with temporary filenames on the server). If there's some reason OOo needs to rely on this part of the POSIX spec for temporary files (i.e. if deleting a temporary file and having it remain accessible is crucial to some part of OOo's functioning), then that's different -- then it's a case of OOo not working because part of the POSIX spec isn't met. But if these temporary files are not important (and as far as I can tell they aren't), then this problem should not cause a crash. (Incidentally, if OOo followed the filesystem hierarchy standard and put its temp files in /tmp instead of the user's homedir, this wouldn't be an issue.) - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@framework.openoffice.org For additional commands, e-mail: issues-h...@framework.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[framework-issues] [Issue 113207] OOo relies on temporary f iles existing after unlink
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=113207 Issue #|113207 Summary|OOo relies on temporary files existing after unlink Component|framework Version|OOO320m19 Platform|PC URL| OS/Version|Linux Status|UNCONFIRMED Status whiteboard| Keywords| Resolution| Issue type|DEFECT Priority|P3 Subcomponent|code Assigned to|tm Reported by|thetrivialstuff --- Additional comments from thetrivialst...@openoffice.org Fri Jul 16 18:48:29 + 2010 --- On Linux (and other unix-like systems), files remain accessible after an unlink () call, via any still-open file descriptors to them. OpenOffice (improperly, in my opinion) relies on this behaviour during startup, and crashes without any error messages at all if this behaviour is not present (as may be the case on networked filesystems, where an unlink() results in the file server removing the file on its end and denying further access to the client). When a file is unlink()ed on a mounted network share (in this specific case, a Samba share), it is immediately removed and cannot be written to after that. OpenOffice attempts to call ftruncate() on an unlink()ed file on startup, and immediately and silently crashes when ftruncate() returns -1 ENOENT (No such file or directory). This is most evident when a user's home directory is on a mounted Samba share, because OpenOffice tries to create a temporary file in the user's home directory on launch, immediately deletes it, then tries ftruncate(). The fact that OpenOffice tries to create a temporary file in a user's homedir is another bug: 106300 . Fixing that issue will also fix this issue, but I am filing this separately because it may be present in other areas of the code (i.e. OpenOffice may try in other circumstances to operate on unlinked() files). Steps to reproduce: - Create a Samba share - Mount it on a workstation - Set a user's home directory on the workstation to be the mounted Samba share - Log in as that user and try to run OpenOffice - OpenOffice shows the splash screen for a moment, then immediately exits. Here are the results of an strace of this part of OpenOffice's startup: STRACE #1: OpenOffice starting successfully (when run with a user's home directory on a local filesystem that allows access to deleted files): open(/var/cache/felix/openoffice//.execoooBw6Q4H, O_RDWR|O_CREAT|O_EXCL, 0600) = 23 unlink(/var/cache/felix/openoffice//.execoooBw6Q4H) = 0 ftruncate(23, 4096) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 23, 0) = 0xb4163000 mmap2(NULL, 4096, PROT_READ|PROT_EXEC, MAP_SHARED, 23, 0) = 0xb4162000 time(NULL) = 1279301195 time(NULL) = 1279301195 open(/usr/lib/openoffice/basis-link/share/config/slots.cfg, O_RDONLY| O_LARGEFILE) = -1 ENOENT (No such file or directory) access(/usr/lib/openoffice/basis-link/share/config/slots.cfg, F_OK) = -1 ENOENT (No such file or directory) getcwd(/home/felix, 4096) = 12 STRACE #2: OpenOffice crashing on startup (when run with a user's home directory on a remote filesystem that does NOT allow access to deleted files): open(/home/felix/.execooo0i873n, O_RDWR|O_CREAT|O_EXCL, 0600) = 23 unlink(/home/felix/.execooo0i873n)= 0 ftruncate(23, 4096) = -1 ENOENT (No such file or directory) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 23, 0) = 0xb4075000 mmap2(NULL, 4096, PROT_READ|PROT_EXEC, MAP_SHARED, 23, 0) = 0xb4074000 --- SIGBUS (Bus error) @ 0 (0) --- After this, OpenOffice goes into a death spiral of various read()s, and eventually dies with a call to exit_group(). While it's true that POSIX file semantics say that files should remain accessible through open descriptors after unlink() (and that this is arguably a problem with the CIFS filesystem driver), OpenOffice should still not rely on this during startup, especially not for writing files that are not necessary for its operation, in a directory where it has no business creating them. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@framework.openoffice.org For additional commands, e-mail: issues-h...@framework.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h
[sc-issues] [Issue 5556] NF-DATE: Date format is not consistent, for ISO 8601 input a correspondin g cell format should be applied and input line should match.
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=5556 --- Additional comments from thetrivialst...@openoffice.org Sun Jun 6 08:59:07 + 2010 --- OK, I'm late joining in on this bug, but it's annoyed me for many years. I thought I understood what was really going on here, but it appears I don't. Here's me being as clear as I can be: - I want ISO 8601 dates in OO Calc. I want to be able to *edit cells* in ISO 8601. - According to the this is not a bug camp, when editing date values OO uses the system locale. - I edited my system locale files to use ISO 8601 for en_GB (my preferred locale), ran locale-gen, and logged off and back on. - Other programs are using ISO 8601 now, so I think I did it correctly. - OO Calc is still using the original en_GB date format! (At least it's not en_US...) So, either I've missed something while editing my locale files, or OpenOffice is using its own copies of the various locales. I really hope that's not the case, and I fervently hope that that's not by design if it is. Doesn't that completely break how locales are supposed to work? Can someone help me out here? WHAT DO I NEED TO DO TO GET ISO 8601 DATES IN CELL EDITING? And more importantly, WHAT DO I NEED TO DO TO GET IT IN ENGLISH? If this is not a bug, answer those two questions, please. If there is no way to get ISO 8601 in English, THAT IS A BUG. End of debate, and someone needs to fix it. (BTW, I already tried setting OO to Hungarian -- it has a two-digit year, so that won't do. Lithuanian... well, we'll see. I was amused to see that in the default format, today's date comes out as 2010 metų birželio mėnesio 6 diena.) It also bears pointing out that in various places in the OO user interface, dates are shown in American format regardless of the program or system locale (have a look at the Calc Calculate options, for instance). That might explain some of the deafness this bug appears to be falling on - the developers are comfortable with month-day-year, and don't understand why anyone would want anything else. So, here's a brief list of things ISO 8601 can do that month-day-year can't: - be unambiguous. - sort lexicographically (e.g. 2009-02-13 comes before 2010-01-13 even when you're sorting as text, whereas m-d-y would give you ). - avoid y2k problems (a lot of people using m-d-y still seem to write only two digits for the year -- which is part of this bug, too). - be consistent with how you write times -- larger units go in front of smaller ones. You wouldn't like a watch that formatted minutes:seconds:hours, so why would write your dates that way? - if you only care about the year and month, or only the year, you can chop off the rest and it's still unambiguous: 2010-06, or 2010. Give it a try; you might like it. (But you might have to fix this bug first if you want to try it in OpenOffice ;) ) - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@sc.openoffice.org For additional commands, e-mail: issues-h...@sc.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[sw-issues] [Issue 21424] Compare documents is non-i ntuitive
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=21424 --- Additional comments from thetrivialst...@openoffice.org Sat May 23 20:26:12 + 2009 --- Will somebody please fix this? It's annoyed me at least as long as this complaint has been up. I don't care which order the comparison operation works in, as long as it's more clearly labelled in the UI. Since this feature has been backwards for so long, it probably can't be changed at this point because it would mess up everyone who's learned it the way it is now. However, there might be some merit in changing it since we still have a minority market share and MS Office does it the other way around (one less thing for converts to complain about). So, in order of preference, here are the solutions I suggest: - Fix the backwardness entirely, and make it so that to compare two documents the user opens the older document, and then selects the newer revision from Edit Compare Documents. - Offer a choice while viewing the document to see either Changes from file1.odt to file2.odt or Changes from file2.odt to file1.odt so that the order in which the user opened the files doesn't matter. Also offer just file1.odt and just file2.odt the way MS Office does (equivalent to Final document only and Original document only, but adding the filenames makes it much clearer which document is which). If the filenames are the same, show differences in the path, e.g. The document in /home/user/e-mail attachments and The document in /home/user/Documents. - Show the filenames alongside hilighted edits, to make it really clear whether a bit of text is from file1.odt or file2.odt . - Provide both options by modifying the the file chooser dialogue for Edit Compare Documents. It would be awesome if the dialogue said the document I am selecting is [Older] [Newer] than the current one and let the user pick the default behaviour, so that those of us who use both OpenOffice and MSOffice can make them behave the same. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@sw.openoffice.org For additional commands, e-mail: issues-h...@sw.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
