After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 168581 - Save functionality is unsafe
Save functionality is unsafe
Status: RESOLVED FIXED
Product: Gnumeric
Classification: Applications
Component: General
git master
Other All
: Normal normal
: ---
Assigned To: Jody Goldberg
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2005-02-26 12:02 UTC by Han-Wen Nienhuys
Modified: 2005-03-31 15:10 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Han-Wen Nienhuys 2005-02-26 12:02:46 UTC
Please describe the problem:
Due to a problem I still have to figure out (I guess some kind of library
mismatch), the XML saver failed, with 

Fout bij opslaan bestand.
Niet in staat om module bestand
"/usr/lib/gnumeric/1.4.2/plugins/xml_sax/xml_sax" te openen
/usr/lib/gnumeric/1.4.2/plugins/xml_sax/xml_sax.so: undefined symbol:
g_assert_warning

(error while saving, cannot open module xml_sax )

At this point, the to-be-written file is truncated.  I was editing an existing
file, and lost it completely. 

This is unacceptable.

(Version : gnumeric 1.4.2 from Fedora Core 3)

No backup is made before  


Steps to reproduce:
1. 
2. 
3. 


Actual results:


Expected results:


Does this happen every time?


Other information:
I think the proper behavior for saving file is to move the file to a backup, write 
the new file, and (optionally) unlink the old one.
Comment 1 Andreas J. Guelzow 2005-02-26 16:17:17 UTC
Your suggested method requires more liberal permissions on the target directory.

The "critical" part of coure is really that your installation is apparently
messed up.
Comment 2 Morten Welinder 2005-02-26 16:59:43 UTC
There is really nothing we can do if someone miscompiles Gnumeric.
What distribution?  (I am guessing Fedora.)

*** This bug has been marked as a duplicate of 165709 ***
Comment 3 Han-Wen Nienhuys 2005-02-26 19:16:09 UTC
You are misinterpreting my bugreport. The point is not that there's something
wrong, but that Gnumeric removes the old file before writing the new file,
creating a window of opportunity where program errors lead to lost data. IMO,
this is inexcusable.

Said directory was owned by me and had permissions 775. How much more liberal
should the permissions be? 

Distribution is FC3 - but as I explained this is besides the point.
Comment 4 Han-Wen Nienhuys 2005-02-26 19:19:15 UTC
sorry, messed up previous comment. It should read
 
The point is not that there's something wrong with the binary/distribution, but 
but that Gnumeric removes the old file before writing the new file,
creating a window of opportunity where program errors lead to lost data. IMO,
this is inexcusable.
Comment 5 Morten Welinder 2005-02-26 19:31:10 UTC
I actually didn't mean to mark this as a dupe.  I wonder how I did that.

We write to a temporary file, then rename that on top after we're done.  I wonder
if libgsf has the ability to abort a write in the middle.
Comment 6 Han-Wen Nienhuys 2005-02-26 19:34:05 UTC
aha, so this is really curious. Any idea how I could debug this? 
Comment 7 Morten Welinder 2005-03-31 14:20:20 UTC
Re the missing symbol, please have a look at

http://groups-beta.google.com/group/linux.debian.bugs.dist/browse_thread/thread/542235315cc85aea/1637a732079fa0f8?q=gnumeric&rnum=3#1637a732079fa0f8

Re the overwrite, I believe this is fixed in libgsf (cvs HEAD branch).
Comment 8 Morten Welinder 2005-03-31 15:10:36 UTC
Fixed in cvs HEAD, between libgsf, goffice, and gnumeric.