Issue 110781 - [MacOSX] "export" to overwrite an existing document: freezes / crashes
Summary: [MacOSX] "export" to overwrite an existing document: freezes / crashes
Status: CLOSED FIXED_WITHOUT_CODE
Alias: None
Product: porting
Classification: Code
Component: code (show other issues)
Version: current
Hardware: Mac Mac OS X 10.6
: P3 Trivial (vote)
Target Milestone: ---
Assignee: Martin Hollmichel
QA Contact: issues@porting
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-04-11 17:01 UTC by wirsberg
Modified: 2016-04-09 10:29 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description wirsberg 2010-04-11 17:01:10 UTC
OOo freezes / crashes after
"export" / "export to pdf" to overwrite an existing document
===============================================================
===
platform: Mac OSX 10.6.3 German (MacMini)

"export"  / "export to pdf"  to a _changed_ filename or different location where a file of the same name 
exists already. 

Occasionally it starts to work as expected: a dialog appears to confirm overwrite, but ends with an error 
message "Error saving the [document]: Write Error. The file could not be written."

Mostly, the export dialog disappears, and leaves the document window's contents frozen (spreadsheet 
/ word processor / presentation) 

Once, OOo crashed completely 
(presentation module, trying to export as an html document)

Once, the whole OOo process freezed 
after trying to "export" a Word processor document to a html file of the same name (but with .html 
extension) in the same location. 

Export options were standard. Nothing changed.

The OOo process owner was identical to the files' owner.

The OOo application can't be safely quit from the "OpenOffice" menu. The "Quit" command closes the 
document window normally, asking to save / not to save. Then OOo gets stuck for ca 1 minute. 

This misbehaviour does not occur on OOo 2.4 on Debian linux.

I tried to figure out environmental influences but I couldn't figure out any:
-----------------------------------
German localization or US-English localization seems to make no difference. 

Tried to "export" to overwrite different files within the same local user's home directory.

the files to be overwritten had permissions: -rw-r--r--@ ; -rw-r--r-- ; -rw-rwx---@   ; I didn't 
detect any correlance of OOo behaviour to these different permission sets. 

The bugous behaviour appeared with new, unsaved documents; as with OOo documents opened from 
disc.

I suspected an influence from the autosave function. But It seems not.
Comment 1 florian 2010-04-11 22:06:50 UTC
How often (in percent) does this happen? And what do you meam with current version? The official 3.2.0 
or a current build for the upcoming 3.2.1. I tried to export to both html and pdf twice with each version 
(official OOo3.2.0 and OOO320m14) and experienced the behaviour once with the official 3.2.0 exporting 
to pdf.
Comment 2 wirsberg 2010-04-13 19:23:21 UTC
I experienced a freeze by more than 50% of similar trials. Not a real-world test.
My version is OOo 3.2.0.
Comment 3 wirsberg 2011-01-19 19:00:26 UTC
[solved]
the encountered OOo misbehaviour and crashes in the context of the "save [as]" dialog were a result of 
a wrong setting in my MacOS X user account. 
The path to my home folder was 
"Volumes/VolName/Users/MyUser". Must be:
 "/Volumes/..." (starting with a slash)

Don't know how this happened. Probably years ago when I set up my system on MacOS 10.5.x. 
I happily found this errornous basic setting when exploring the MacOS Server admin tool "Workgroup 
Manager" (part of the "Server Administration Tools" from Apple). Now everything works fine. Also 
"Terminal" finally has found its home settings in the expected path. :-) 
Comment 4 Marcus 2016-04-09 10:29:03 UTC
resolved by user