bugGNU nano - Bugs: bug #36864, saving to a full device can lead...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #36864: saving to a full device can lead to emptying the file

Submitter:  Clarence Risher <sparr>
Submitted:  Tue 17 Jul 2012 04:07:24 PM UTC
   
 
Severity:  4 - Important Status:  Wont Fix
Assigned to:  None Open/Closed:  Closed

Jump to the original submission

Mon 14 Mar 2022 04:33:49 PM UTC, comment #16: 

Yes, that ^X Y, or ^O ^M, or simpy ^S, can cause the file on disk to be truncated to zero bytes is the bug.  I've adjusted the subject line to make this clearer.

Benno Schulenberg <bens>
Group administrator
Mon 14 Mar 2022 03:15:16 PM UTC, comment #15: 

I propose that a ^X Y failure leading to the original file on disk being lost is the bug, before any further [lack of] interaction from the user. Some of the comments here are about losing data in the buffer that couldn't be written to disk being user error, and I think that could be reasonable. However, that reasoning does not extend to losing data that was already stored on the disk.

Clarence Risher <sparr>
Thu 03 Mar 2022 04:11:12 PM UTC, comment #14: 

If you can't make room, or other processes eat the space up immediately, then... well, you're screwed, nano can't help you there.

As said, when you edit a buffer, and then do ^X N, nano does not touch the file on disk at all -- the file will stay intact.  But if you do ^X Y, and that fails, and then you do ^X N, then the file has already been truncated by the ^X Y -- nano cannot undo that.

Benno Schulenberg <bens>
Group administrator
Thu 03 Mar 2022 12:36:46 PM UTC, comment #13: 

Hey guys!
I looked at the patch, it does help, but there's one use case: if the disk the user is trying to edit is full, and you're asking "make room" and for whatever reason that's not possible... Let's say you're on a machine that has no other attached disk, even /tmp is full. Also logging daemons might go nuts and consume all disk space, even when someone starts deleting stuff around to make space.
What I think happens, nano is wrongly trying to save the buffer on exit.
I might be wrong but I don't remember trying to "write" the file, just plain exiting. Even when the buffer changed, do you think the file should be touched at all with ^X N?
When I mentioned the swap, if I did the mistake of trying to save, which might make more sense, I would expect to have a copy of the previous file there, that's the purpose of it, right?
Benno, I think your solution making the buffer unmodifiable with NOSPC is a great idea.
I really appreciate the help here and the code change that hopefully will prevent other people to go through the same problem in the future.

Lucas Freitas <lucasff>
Thu 03 Mar 2022 10:19:21 AM UTC, comment #12: 

The issue has been mitigated somewhat in git, commit 47c11ae8, by giving an extra warning about the file having been truncated, plus a suggestion on how to proceed:

  https://git.savannah.gnu.org/cgit/nano.git/commit/?id=47c11ae8

Benno Schulenberg <bens>
Group administrator
Tue 01 Mar 2022 12:26:33 PM UTC, comment #11: 

Would something like the attached patch be helpful?  It prevents the user from simply exiting after a write failure due to an ENOSPC ("No space left on device").

(file #52943)

Benno Schulenberg <bens>
Group administrator
Mon 28 Feb 2022 04:37:04 PM UTC, comment #10: 

Lucas, if you really did Ctrl+X (whereupon nano asked "Save modified buffer?") and you typed N, then nano will not touch the existig file at all.  But when you type Y to that question, then you risk losing the file if the disk is full.

I don't see what the "swap" file (the lock file, you mean, right?) has got to do with it.  But when you get a warning that the lock file could not be written... you should be alarmed and back out as soon as possible.  (Maybe nano can help there by setting the buffers unmodifiable when that writing fails due to a "No space" error?)

Benno Schulenberg <bens>
Group administrator
Mon 28 Feb 2022 02:46:22 PM UTC, comment #9: 

Hello all. I know this an old bug/thread but I wanted to pitch in. I got bitten by this bug yesterday. I assume this is related to the "swap" file that nano creates and therefore fails in an empty disk.
I consider this absolutely a bug. Does vim for example have the same behavior under the same conditions?
The fact that the file would be truncated and overwritten, even though the file already exists on a disk, is definitely a bug.
I do remember seeing a big red box, but my assumption was "the file is already on the disk, I don't want to change anything, please don't touch it all and keep as is" with the C-X N action.

Lucas Freitas <lucasff>
Tue 01 May 2018 05:45:34 PM UTC, comment #8: 

Hmm...  The thing is, probably, that when writing the current, modified buffer fails due to "No space left", that then the user assumes that the original file is still on the disk and they can therefore safely discard the current buffer and do ^X N.  In fact, I cannot blame them.  And it would be nice if things indeed worked that way: nano shouldn't truncate and rewrite the target file, it should instead write a temp file, and when that has succeeded, move that temp file over the target file.

Benno Schulenberg <bens>
Group administrator
Sat 03 Mar 2018 10:38:23 AM UTC, comment #7: 

Indeed, when I apply the attached testing patch (which pauses for twelve seconds after opening the file for writing), and then run 'nano box/color.c' and type ^R NEWS <Enter> ^O <Enter>, and then in a second terminal do:

  dd if=NEWS of=box/grabbed bs=1K count=14

and then go back to the first terminal and wait for the message, it says "No space left".  When I then exit (^X N) and reopen box/color.c, then indeed it is empty, zero bytes.

So, nano will only "lose the file" when there is writing pressure on the target disk: other processes writing to that disk.  And the user will only lose the file when they exit and say No.

When they exit, they shouldn't say No when there was a writing error (or any error), they should instead try and save their buffer somewhere else, temporarily.  To exit from nano when it reports an error when you tried to save the buffer is not a good idea -- if you want to keep the data.

So... I would tend to ascribe this loss of data to user error.  (Which will probably happen less nowadays, now that we have a default errorcolor of brighwhite on red, which should help to convey a sense of urgency.)

(file #43440)

Benno Schulenberg <bens>
Group administrator
Thu 01 Mar 2018 06:33:39 PM UTC, comment #6: 

Bug #30786 has been marked as a duplicate of this report.

Benno Schulenberg <bens>
Group administrator
Thu 01 Mar 2018 05:10:53 PM UTC, comment #5: 

Hello Clarence and David and anonymous,

I cannot reproduce this.  As I didn't have a filesystem handy that I can fill up without consequences, I did the following:

dd if=/dev/zero of=fakedevice bs=1M count=50
mkfs.ext4 fakedevice
sudo losetup --show -f fakedevice
mkdir box
sudo mount fakedevice box
sudo chown ben: box
# Copy some real files to the loop device:
cp src/*.c box/
# Now fill up the rest of the thing:
cat /dev/zero >box/stuffit
# Check whether the box really has zero bytes left:
df -h | grep box
# The device still had 2,0K left, so I did:
nano box/extra
# and typed ^R NEWS <Enter> ^O <Enter> ^X N
# It complained about "No space left", but looking at
# box/extra, it contained the first 2048 bytes of NEWS.

Now, when I edit box/color.c, make some changes (without increasing the size), and save (^O <Enter>), the file is properly saved, no complaint about no room left.  And if instead of making changes, I insert a large other file at the end of it (for example, doc/faq.html), then upon saving it, it complains about no room left, but it has written the file -- the file is just truncated to the size that was available (the blocks that were already allocated to box/color.c).

Then I've also tried it on a mounted USB stick: filled it up, edited an existing file on the stick, made it much larger, saved it, nano complained about no room, but the resulting file is not zero size, it is just "truncated": it stops where the earlier allocated blocks ran out.

The only thing I can think of how one could end up with a zero-size file is that, when you hit ^O <Enter>, nano opens the file for writing, which causes it to be truncated to size zero, and before nano can even start writing, some other process grabs the just freed blocks and fills them up, leaving nano with "No space left" when it begins to write the contents of the buffer.

If the painted scenario cannot be the cause of a zero-size file, please give me a detailed reproduction recipe.

Benno Schulenberg <bens>
Group administrator
Mon 14 Jul 2014 10:31:35 PM UTC, comment #4: 

Hi!

This just happenned to me on debian wheezy, everything up-to-date.

I did :
nano /my/external/mounted/drive/myfile

and when I saved it, nano said "no enough place" or somethings, and then the file was empty. I'm kinda broken now, this file was a scratchpad full of important stuff !


I still couldn't get my file back, by the way.


nano version : nano GNU version 2.2.6 (compilé à 21:40:01, le Jun 22 2012)


That said (not sure if this place is good for that by the way), I will be more carefull next time !


Thanks

Anonymous
Wed 05 Feb 2014 05:34:43 PM UTC, comment #3: 

I also did the same thing with nano-2.3.2-2.1.2.x86_64 provided by open suse 13.1.

david <ballsystemlord>
Wed 05 Feb 2014 05:32:25 PM UTC, comment #2: 

Hi, I recreated this bug by repartitioning my hard disk.
I checked out your source about a month ago so I compiled it
and called it nano2. Then, to let you see where you are in the program I produced a core dump.

% ulimit -c $((2**32))
% nano2 nano-how-to-contrib.html
% stat nano-how-to-contrib.html
  File: ‘nano-how-to-contrib.html’
  Size: 0               Blocks: 0          IO Block: 1024   regular empty file
Device: 80dh/2061d      Inode: 509         Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/ballsystemlord)   Gid: (  100/   users)
Access: 2014-01-24 20:02:26.000000000 -0500
Modify: 2014-01-24 20:02:26.000000000 -0500
Change: 2014-01-24 20:02:26.000000000 -0500
 Birth: -
% ps -a | grep nano
 6772 pts/1    00:00:00 nano2
% kill -s SIGSEGV 6772 #I tried using SIGQUIT but it did not work.
% nice -n 10 xz -k -C sha256 -v --lzma2=dict=2MiB,lc=4,lp=0,pb=2,mf=bt4,mode=normal,nice=273,depth=1000 "core"


(file #30464)

david <ballsystemlord>
Thu 10 Jan 2013 03:56:53 AM UTC, comment #1: 

Hello.  Can you let me know what version of nano you were using?  There have been several sets of fixes for full files in various versions, but they have not gone back to all stable branches.

Chris Allegretta <astyanax>
Group administrator
Tue 17 Jul 2012 04:07:24 PM UTC, original submission:  

I was editing a file on a full partition. Attempting to save it yielded an error that the device was full, which was ok. The problem is that this left the file on disk in a zero byte state. This should not happen.

Clarence Risher <sparr>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #43440:  pause-after-opening.patch added by bens (464B - text/x-patch)
file #30464:  core.xz added by ballsystemlord (51KiB - application/x-xz)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by lucasff (Posted a comment)
  • -email is unavailable- added by bens (Posted a comment)
  • -email is unavailable- added by ballsystemlord (Updated the item)
  • -email is unavailable- added by astyanax (Posted a comment)
  • -email is unavailable- added by sparr (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 14 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-03-14 bens Summarysaving to a full device can lead to an empty file saving to a full device can lead to emptying the file
    2022-03-14 bens Open/ClosedOpen Closed
    2022-03-03 bens StatusNone Wont Fix
    2022-03-01 bens Attached File- Added 0001-files-prevent-the-user-from-just-exiting-after-a-No-.patch, #52943
        StatusNeed Info None
    2020-11-11 bens Assigned tobens None
    2020-07-17 bens Summarysaving to full device leads to empty file saving to a full device can lead to an empty file
    2018-03-03 bens Attached File- Added pause-after-opening.patch, #43440
    2018-03-01 bens Assigned toastyanax bens
        SummarySaving to full device leads to empty file saving to full device leads to empty file
    2014-02-05 ballsystemlord Attached File- Added core.xz, #30464
    2013-01-10 astyanax Severity3 - Normal 4 - Important
        StatusNone Need Info
        Assigned toNone astyanax

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code