Issue 73854 - Save to ODF: Basic project lost when saving to USB device
Summary: Save to ODF: Basic project lost when saving to USB device
Status: ACCEPTED
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: OOo 2.1
Hardware: PC Windows XP
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-01-25 10:27 UTC by daniel.rentz
Modified: 2017-05-20 10:48 UTC (History)
2 users (show)

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

Attachments
Test document with macto function "TEST()" (7.44 KB, application/vnd.oasis.opendocument.spreadsheet)
2007-01-25 10:29 UTC, daniel.rentz 		no flags Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description daniel.rentz 2007-01-25 10:27:03 UTC 
Reproduced on a laptop with Windows XP Home and a connected USB mass 
storage device:

- Create a Calc document, add a simple macro, or even an empty Basic module.
- Save document to the USB device.
- Do NOT close the document, switch off the laptop (standby or hibernate).
- Connect the USB device to another USB port.
- Switch on the laptop.
- Change something in the open document, try to save.
-> "General I/O error"
- Try to save document with another file name
-> No error message
- Close and reload document
-> ** Basic container is empty **

Happens with Basic code and with dialogs.
Comment 1 daniel.rentz 2007-01-25 10:29:48 UTC 
Created attachment 42452 [details]
Test document with macto function "TEST()"
Comment 2 daniel.rentz 2007-01-25 10:31:06 UTC 
attached a test document, contains a Basic function "TEST()" that returns the 
text "Macro exists" and is used in cell A1. If the macro is missing, a #NAME! 
error occurs in the cell.
Comment 3 daniel.rentz 2007-01-26 08:46:40 UTC 
target
Comment 4 daniel.rentz 2007-06-20 13:38:45 UTC 
fixed in SRC680/dr55 (OOo 2.3)
Comment 5 daniel.rentz 2007-06-20 13:39:38 UTC 
wrong issue, reopening...
Comment 6 mikhail.voytenko 2007-07-17 10:00:45 UTC 
This looks exactly like a duplicate to the bug 73979. The only difference is
that in this case not a network file handle is corrupt, but a file handle on UCB
device. I do not close this issue as duplicate to let the scenario be tested by QA.
Comment 7 mikhail.voytenko 2007-07-20 10:06:40 UTC 
Changing the target.
Comment 8 mikhail.voytenko 2007-09-07 15:53:52 UTC 
Ok, the issue 73979 triggers the problem. But in this case the error should be
shown instead of data-loss. The problem is that the basic API (
XLibraryContainer ) does not allow any kind of error report, so in case the
basic library can not be stored the error can not be detected.

In this case the exception is thrown by the "XStorage::copyElementTo()" method
in namecontainer.cxx:1798. Unfortunately there is no way to transport the error.

MAV->AB: Could you please take a look.
Comment 9 ab 2007-09-11 07:12:22 UTC 
STARTED
Comment 10 ab 2007-11-14 14:28:35 UTC 
The general problem is covered by i73979. This issue 
only addresses the error reporting problem -> 3.x
Comment 11 Marcus 2017-05-20 10:48:13 UTC 
Reset assigne to the default "issues@openoffice.apache.org".