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.
>
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
