bugGNU nano - Bugs: bug #36864, saving to full device leads to...


bug #36864: saving to full device leads to empty file

Submitted by:  Clarence Risher <sparr>
Submitted on:  Tue 17 Jul 2012 04:07:24 PM UTC  
Severity:  4 - Important Status:  Need Info
Assigned to:  Benno Schulenberg <bens> Open/Closed:  Open

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
Mon 14 Jul 2014 10:31:35 PM UTC, comment #4:


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 !


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>
Project 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.)

Attach Files:

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 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)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.




    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    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.3