Problem with mkfs.xfs on a regular file

[Eric Sandeen]

On 11/28/13, 4:01 AM, Dave Chinner wrote:
> On Wed, Nov 27, 2013 at 11:34:35PM -0600, Eric Sandeen wrote:

<snip>

>> Or maybe just stat() it, and DTRT?
> 
> Well, we need to stat it to make sure that it's a file if "-d file"
> is specified, and a block device if it's not. That will prevent this
> problem.  Every other xfsprogs utility has to be told that it is
> being pointed at an image file rather than a block device, so why
> should mkfs be any different?

The option is there but again I never really knew why.  They work
fine without -f, at least in general:

$ xfs_db fsfile
xfs_db> 

$ xfs_repair fsfile
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
        - scan filesystem freespace and inode maps...
...

$ xfs_metadump fsfile fsfile.meta

$ file fsfile.meta
fsfile.meta: XFS filesystem metadump image

etc

> Indeed, if we don't require users to tell mkfs that it's a file,
> what do we do with non-existent  device names when they are provided
> by the user? Just create the file rather than returning ENOENT? So
> suddenly /dev/ fills up with fileystem images because of typos?

That won't happen because it doesn't create a new file unless -d file
is specified, so I guess that's one difference.  i.e. with -d file
it'll create a file of the requested size; without it, it will mkfs
it to whatever size the file already is, or if it doesn't exist,
return -ENOENT.

> Principle of Least Surprise says that ENOENT is the correct
> behaviour, hence it follows that "-d file" is needed and should be
> properly checked and enforced. I'll add this to the start of the
> patch set I'm currently working on that fixes all of the mkfs input
> parameter validation problems I've found over the past couple of
> weeks...

Well, I hope it doesn't stop mkfs.xfs from mkfs'ing an existing
file image, which has always worked before...

Thanks,
-Eric

> Cheers,
> 
> Dave.
>