[framework-issues] [Issue 113207] OOo relies on temporary f iles existing after unlink

2010-10-30 Thread thetrivialstuff
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

2010-10-14 Thread mav
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 m...@openoffice.org Thu Oct 14 11:16:27 + 
2010 ---
Hm, I still do not understand why shouldn't OOo rely on POSIX specification.
If a filesystem driver has a bug, it should be fixed there I assume.

-
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

2010-07-17 Thread ja
To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=113207


User ja changed the following:

What|Old value |New value

  CC|''|'mav'





--- Additional comments from j...@openoffice.org Sat Jul 17 08:58:23 + 
2010 ---
ja-mav: please take a look at this

-
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

2010-07-16 Thread thetrivialstuff
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: