| 2019-11-08 19:12:55 |
mlg7 |
description |
I encountered this problem when I was backing up my data to an ext4 drive.
As I understand, the problem will happen with any editor and likely with any other program.
When disk is full, files are erased when you try to save them.
Scenario 1 (exactly as it happens in real life, but slow)
1. Take an ext4 drive. Fill it with data almost completely (like 10G free on a 500G grive)
2. Create a multi-line text file (like 10 lines of 10 characters each)
3. Start a terminal with a bash shell; run ``sudo mc'' (that is, run Midnight Commander as root)
4. navigate to a directory containing about 25G of data; use Midnight Commander to copy that directory to the almost full ext4 disk. Surprisingly, that operation will succeed: about 5% of disk space is reserved for root's needs. For some time you will be watching as mc copies gigabytes of data to a disk that, according to df, has no free space.
5. Open the file created on step 2 with vi, or gedit, or mcedit (not from under root!) and delete one line. Press "Save". The editor (mcedit) shows the following warning: "The file has been modified in the meantime. Save anyway?" but it is already not important which button you press: your file is erased (truncated to zero length).
Expected result: the new contents replace the old contents of the file, finally, there must be enough room because the file already exists
Actual result: the length of file becomes 0, all your data is lost (with any of: vi, gedit, mcedit).
In fact, if you have a full disk where root's quote is partially used, you can repeat it without copying of gigabytes of data. Just create a file testfile.txt from root and:
me@comp:/more/Documents$ cat testfile.txt
one
two
three
four
me@comp:/more/Documents$ sudo cp testfile.txt mytestfile.txt
me@comp:/more/Documents$ ls -l mytestfile.txt
-rw-r--r-- 1 root root 19 Nov 7 21:05 mytestfile.txt
me@comp:/more/Documents$ sudo chmod a+rw mytestfile.txt
me@comp:/more/Documents$ ls -l mytestfile.txt
-rw-rw-rw- 1 root root 19 Nov 7 21:05 mytestfile.txt
me@comp:/more/Documents$ cat mytestfile.txt
one
two
three
four
me@comp:/more/Documents$ mcedit mytestfile.txt
F2 (Save)
Confirm save file: "/more/Documents/mytestfile.txt"
[ Save ]
Enter file name:
/more/Documents/mytestfile.txt
The file has been modified in the meantime. Save anyway?
[ Yes ] [ Cancel ]
me@comp:/more/Documents$ ls -l mytestfile.txt
-rw-rw-rw- 1 root root 0 Nov 7 21:09 mytestfile.txt
me@comp:/more/Documents$
me@comp:/more/Documents$ cat mytestfile.txt
me@comp:/more/Documents$
me@comp:/more/Documents$ mount | grep more
/dev/sda1 on /more type ext4 (rw,relatime,errors=remount-ro)
me@comp:/more/Documents$ df | grep more
/dev/sda1 480085744 471624064 0 100% /more
me@comp:/more/Documents$ df -h | grep more
/dev/sda1 458G 450G 0 100% /more
Scenario 2 (less realistic, but faster)
1. Take an ext4 drive. Fill it with data almost completely (like 10G free on a 500G grive). Run df and see how much space is left.
2. From under root, write more data than df reported on the previous step to the drive. (Surprisingly, that operation will succeed: about 5% of disk space is reserved for root's needs.)
3. From under root, create a multi-line text file (like 10 lines of 10 characters each). Allow read-write access for anyone.
4. Open the file created on the previous step with vi, or gedit, or mcedit (not from under root!) and delete one line. Press "Save". The editor (mcedit) shows the following warning: "The file has been modified in the meantime. Save anyway?" but it is already not important which button you press: your file is erased.
Expected result: the new contents replace the old contents of the file, finally, there must be enough room because the file already exists
Actual result: the length of file becomes 0, all your data is lost (with any of: vi, gedit, mcedit).
I will not discuss here what component is to blame; it is possible to say that all editors are buggy, but IMO, if you ask me, it is the file system that behaves counterintuitively. |
I encountered this problem when I was backing up my data to an ext4 drive.
As I understand, the problem will happen with any editor and likely with any other program.
When disk is full, files are erased when you try to save them.
Scenario 1 (exactly as it happens in real life, slow because of copying gigabytes)
1. Take an ext4 drive. Fill it with data almost completely (like 10G free on a 500G grive)
2. Create a multi-line text file (like 10 lines of 10 characters each)
3. Start a terminal with a bash shell; run ``sudo mc'' (that is, run Midnight Commander as root)
4. navigate to a directory containing about 25G of data; use Midnight Commander to copy that directory to the almost full ext4 disk. Surprisingly, that operation will succeed: about 5% of disk space is reserved for root's needs. For some time you will be watching as mc copies gigabytes of data to a disk that, according to df, has no free space.
5. Open the file created on step 2 with vi, or gedit, or mcedit (not under root!) and delete one line. Press "Save". The editor (mcedit) shows the following warning: "The file has been modified in the meantime. Save anyway?" but it is already not important which button you press: your file is erased (truncated to zero length).
Expected result: the new contents replace the old contents of the file, finally, there must be enough room because the file already exists!
Actual result: the length of file becomes 0, all your data is lost (with any of: vi, gedit, mcedit).
In fact, if you have a full disk where the root's quote is partially used, you can repeat it without copying gigabytes of data. Just create a file testfile.txt under root and:
me@comp:/more/Documents$ cat testfile.txt
one
two
three
four
me@comp:/more/Documents$ sudo cp testfile.txt mytestfile.txt
me@comp:/more/Documents$ ls -l mytestfile.txt
-rw-r--r-- 1 root root 19 Nov 7 21:05 mytestfile.txt
me@comp:/more/Documents$ sudo chmod a+rw mytestfile.txt
me@comp:/more/Documents$ ls -l mytestfile.txt
-rw-rw-rw- 1 root root 19 Nov 7 21:05 mytestfile.txt
me@comp:/more/Documents$ cat mytestfile.txt
one
two
three
four
me@comp:/more/Documents$ mcedit mytestfile.txt
F2 (Save)
Confirm save file: "/more/Documents/mytestfile.txt"
[ Save ]
Enter file name:
/more/Documents/mytestfile.txt
The file has been modified in the meantime. Save anyway?
[ Yes ] [ Cancel ]
me@comp:/more/Documents$ ls -l mytestfile.txt
-rw-rw-rw- 1 root root 0 Nov 7 21:09 mytestfile.txt
me@comp:/more/Documents$
me@comp:/more/Documents$ cat mytestfile.txt
me@comp:/more/Documents$
me@comp:/more/Documents$ mount | grep more
/dev/sda1 on /more type ext4 (rw,relatime,errors=remount-ro)
me@comp:/more/Documents$ df | grep more
/dev/sda1 480085744 471624064 0 100% /more
me@comp:/more/Documents$ df -h | grep more
/dev/sda1 458G 450G 0 100% /more
Scenario 2 (less realistic, but faster)
1. Take an ext4 drive. Fill it with data almost completely (like 10G free on a 500G grive). Run df and see how much space is left.
2. From under root, write more data than df reported on the previous step to the drive. (Surprisingly, that operation will succeed: about 5% of disk space is reserved for root's needs.)
3. From under root, create a multi-line text file (like 10 lines of 10 characters each). Allow read-write access for anyone.
4. Open the file created on the previous step with vi, or gedit, or mcedit (not under root!) and delete one line. Press "Save". The editor (mcedit) shows the following warning: "The file has been modified in the meantime. Save anyway?" but it is already not important which button you press: your file is erased.
Expected result: the new contents replace the old contents of the file, finally, there must be enough room because the file already exists!
Actual result: the length of file becomes 0, all your data is lost (with any of: vi, gedit, mcedit).
I will not discuss here what component is to blame; it is possible to say that all editors are buggy, but IMO, if you ask me, it is the file system that behaves counterintuitively. |
|
