Bug 1236318

Summary:	RFE: mkfs.ext4: no warning issued when overwriting an unmounted filesystem
Product:	Red Hat Enterprise Linux 7	Reporter:	g.danti
Component:	e2fsprogs	Assignee:	Eric Sandeen <esandeen>
Status:	CLOSED WONTFIX	QA Contact:	Filesystem QE <fs-qe>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	7.1	CC:	g.danti, lmiksik, renich
Target Milestone:	rc	Keywords:	FutureFeature
Target Release:	---
Hardware:	Unspecified
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-01-14 14:15:25 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description g.danti 2015-06-27 17:27:06 UTC

Description of problem:
The mkfs.ext4 utility currently shipping in RHEL 6.6, 7.0 and 7.1 issues NO WARNING when overwriting a valid, but unmounted, filesystem. This is an unacceptable behavior: it suffice a single type (eg: sdaX instead of sdbX) to permanently delete valid (and valuable, perhaps) user data. In general, destructive operations on valid data should issue clear warning and abort, unless specifically told to continue.

As a reference, please see the mkfs.xfs utility, which refuse to overwrite a valid filesystem (even if unmounted).

Version-Release number of selected component (if applicable):
e2fsprogs-1.42.9-7.el7.x86_64

How reproducible:
Create an ext4 filesystem, mount it and write some data, then unmount it and recreate it. The second create operation should clearly warning the user that he is trying to overwrite valid data, and abort _unless specifically told to continue_ (eg: by using a --force parameter)

Steps to Reproduce:
1. mkfs.ext4 /dev/test
2. mount /dev/test /mnt/test; cp -a /etc /mnt/test; umount /mnt/test
3. mkfs.ext4 /dev/test

Actual results:
The second mkfs.ext4 immediately delete all user data on /mnt/test

Expected results:
The second mkfs.ext4 should clearly warning the user that he is trying to overwrite valid data, and abort _unless specifically told to continue_ (eg: by using a --force parameter)

Additional info:
None

Comment 2 Eric Sandeen 2015-06-27 21:39:42 UTC

This is historical behavior of mkfs.ext[234]; it was added only fairly recently in 1.42.10, and RHEL7 ships 1.42.9.  As such, this is more of an RFE than a bug.

commit dbcd617882ee5c9da80d9257475f2594352f6698
Author: Theodore Ts'o <tytso>
Date:   Sat Apr 26 18:42:31 2014 -0400

    mke2fs: check for pre-existing file system
    
    Warn the system administrator if there is an existing file system on
    the block device, and give the administrator an opportunity to abort
    the mkfs operation.
    
    Signed-off-by: "Theodore Ts'o" <tytso>


I have some concern about adding this, because it changes the expected behavior as shipped in RHEL7 GA.

However, the upstream patch does try to address this problem:

        /* The isatty() test is so we don't break existing scripts */
        flags = CREATE_FILE;
        if (isatty(0) && isatty(1))
                flags |= CHECK_FS_EXIST;

so it may be acceptable.

Comment 3 g.danti 2015-06-27 22:42:30 UTC

Hi Eric,
Yes, from RHEL point of view it is more a RFE than a bug report.
Anyway, the test for tty should address any concern about problems for scripts so, please, consider it very seriously for inclusion (if it is possible, obviously). 

Heck, to tell the truth, I would prefer that scripts _fail_ rather than silently delete potentially delete valuable data - but I absolutely understand your reluctantly to such a drastic change.

Comment 4 Eric Sandeen 2015-06-28 00:01:22 UTC

The other thing, of course, is muscle memory - I now reflexively type "mkfs.xfs -f" every time I invoke it, so it's not much of a barrier to disaster ...

-Eric

Comment 5 g.danti 2015-06-28 05:36:12 UTC

Mmm... This really depends... I (unfortunately) learned the hard way that forced operation on destructive command (mkfs, rm, etc.) should be given only if absolutely needed. In other words, I use mkfs.xfs -f very carefully :)

Comment 7 Eric Sandeen 2016-01-14 14:15:25 UTC

While upstream has added this, I'm not going to make the change in RHEL7.  People expect stable behavior in RHEL, and this would be a very user-visible change; some people may prefer it, others may not.

ext2/3/4 has gone without the warning for more than a decade.

New releases of RHEL will have the new behavior, but I'm not going to change it in RHEL7.

Comment 8 g.danti 2016-01-14 15:49:29 UTC

Please reconsider that. Destroying user data *without warnings* is a very bad thing.

Let me describe another scenario: to be checked for errors, an ext4 filesystem must be unmounted. Now, with an unmounted fiesystem, if the user naively (stupidly?) type the wrong command, exchanging 'fsck.ext4' with 'mkfs.ext4' it will *lose all data*

I understand that an user writing a wrong command should blame himself. However, we are humans an errors happens sometime - but they are much more dangerous if the system blindly obey without even raising some warning.

The proposed solution (to complain only when connected to a TTY), would fix the problem without impairing any unattended scripts, so it seems a relatively safe change.

Anyway, thank you for your time.
Regards.

Comment 9 Renich Bon Ciric 2023-01-06 00:49:21 UTC

I wonder what happened with this one? I'm trying it out in a script in RHEL 9 and it still destroys data by default. 

Any news?