[ nedit-Bugs-1027807 ] loss of files on full disk

[SourceForge.net]

Bugs item #1027807, was opened at 2004-09-14 03:13
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=111005&aid=1027807&group_id=11005

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Program
Group: None
Status: Open
Resolution: None
Priority: 9
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: loss of files on full disk

Initial Comment:
Today, september 14th 2004, I noticed something 
unpleasant. I work on my own share of a large company 
server which does not have a very large space. Writing 
text in Latex often requires ps (eps) figures which can 
run big. So, I ran out of space. Unfortunately, nedit 
simply gave the message "can not save, no space on 
device" when I wanted to save a tex file created in 
nedit. The only option I had was to press ok, which I 
did, thinking I would have to re-edit the file after 
making space on my share by removing some old files. 
However, nedit also decided to delete the tex file 
altogether! So, it did not leave the tex file unchanged, 
but the tex file was gone completely. Fortunately, we 
have a good backup system on our server, but I can 
imagine this can be very annoying when working on 
your private computer, running out of space (that can 
happen) and then losing your tex file you have been 
editing on for the last hour or so.

Just wanted to report this, maybe it's not new, but I 
think it is something to recon with.

With regards,

victor land
PhD FOM Institute for Plasma Physics Rijhuizen
The Netherlands

reply: vland at rijnh.nl

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2007-06-19 07:00

Message:
Logged In: NO 

I suppose we can measure an existing file's size and, if smaller than the
require size, try to extend it with fseek() (using fopen(..., "r+b")
first). The opposite, writing a shorter text to a pre-existing file without
emptying it first, requires file truncation; I don't know a standard way to
do that!

The doSave() function copies file buffers around. If no adjustment is
necessary (applying null chars, replacing line endings), it would be good
to simply use the original buffer (BufAsString()) as the source for
writing.

----------------------------------------------------------------------

Comment By: Andrew Hood (ajhood)
Date: 2006-10-01 05:14

Message:
Logged In: YES 
user_id=36856

If we were to replace all uses of fwrite() with code like
this we would be notified there was a problem

ssize_t written;
while((written=write(fd, ptr, bytesleft))>0) {
 ptr+=written;
 bytesleft-=written;
}
if (written<0) {
 DialogF(DF_ERR, window->shell, 1, "Error saving File",
"your file %s is toast because of %s. you'd better save it
somewhere else", window->filename, errorString());
);
 /* cleanup */
}
if (close(fd)<0)) {
 DialogF(DF_ERR, window->shell, 1, "Error saving File",
"your file %s is toast because of %s. you'd better save it
somewhere else", window->filename, errorString());
 /* cleanup */
}
else {
 /* save was OK */
}

----------------------------------------------------------------------

Comment By: Nathan Gray (n8gray)
Date: 2004-09-15 16:54

Message:
Logged In: YES 
user_id=121553

The "remove(fullname);" line in this code is the culprit:

--- code ---
    /* write to the file */
#ifdef IBM_FWRITE_BUG
    write(fileno(fp), fileString, fileLen);
#else
    fwrite(fileString, sizeof(char), fileLen, fp);
#endif
    if (ferror(fp))
    {
        DialogF(DF_ERR, window->shell, 1, "Error saving File",
                "%s not saved:\n%s", "OK", window->filename,
                errorString());
        fclose(fp);
        remove(fullname);
        XtFree(fileString);
        return FALSE;
    }
--- end code ---

The problem is that by this point we may have already written to the file,

probably corrupting it.  Rather than leaving a corrupt file, NEdit deletes

it.  This is arguably a bad idea, but it's incorrect to think NEdit
deleted 
the original, unaltered copy -- it was already overwritten.

The safe way to do this is to create a backup of the file before saving 
and then remove it when the save has completed.  The first half is 
already possible using the "Preferences->Default Settings->Make Backup 
Copy (*.bck)" option.  The only problem is that the backup copy is not 
deleted after the save completes.  

Perhaps we should make it so the default behaviour is "make backup 
copy; save; delete backup copy."  If the user selects "Make Backup 
Copy" then the backup copy would not be deleted.  It would mean saving 
would take extra disk space for a short time, but the only time it would 
cause a problem is when you have enough space for 1 copy of the file 
but not 2.  In this case you're playing with fire anyway!  It would also 
mean saves would take a while longer (either that or the file's inode 
number would change).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=111005&aid=1027807&group_id=11005