On Mon, Mar 15, 2010 at 05:32:48PM +0100, Karel Zak wrote: > The problem with this feature is that mount(2) syscall allows to use > regular files (or whatever) as the source argument. The interpretation > of the source argument completely depends on filesystem driver. So you > can create FS that is able to mount regular files... > > This is reason why we should not automatically create loop devices for > > mount -t foo disk.img /mnt > > because we know nothing about 'foo'. It means that the feature will > be used only when fylesystem type is not specified, for example: > > mount disk.img /mnt > > I guess it's 99% of all use cases. Thanks to Miklos for his comments. Honestly I think doing this is broken. I've done tons of custome one filesystems for customers that just mount a regular file to implement weird semantics I didn't want to throw into a character driver, and it's also possible to do mount --bind or similar namespace manipulation on every type of file. I would strongly suggest to drop this hack, it's really no problem for the user to add -o loop for loop mounts. Especially as we might replace the current loop driver with a more flexible one with a different name in the future, so mount hardcoding loop is not a good thing. -- To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
