On Fri, Jan 25, 2013 at 12:02:01PM -0500, Mike Frysinger wrote:
> On Friday 25 January 2013 10:17:36 Karel Zak wrote:
> > On Sun, Jan 20, 2013 at 06:27:22PM -0500, Mike Frysinger wrote:
> > > we could tweak parse_argv() so that it checks for argv[0] == '.' in
> > > addition to argv[0] == '/'. but that wouldn't fix other relative paths
> > > like: $ fsck images/foo
> > > $ fsck foo
> >
> > Hmm... maybe add a hint to the fsck man page is the best solution :-)
> >
> > > should we treat all non-options as devices ? would that break anything ?
> >
> > I don't think it's a good idea.
> >
> > All unknown stuff is by default interpreted as filesystem specific options
> > (options for fsck.<type>) and it's pretty common that people don't use
> > "--" separator between fsck and fsck.<type> options.
>
> well, i didn't mean non-fsck options, but non-options. i.e. things that don't
I understand..
> start with dashes. are there fscks which use non-options as something other
> than "file/device to check" ?
fsck.ext4 -L bad_block_file /dev/sda1
or whatever... and note that we have no clue about all possible fsck
implementations (not all is public and open source..)
> really, the fsck checking here is simply to determine whether it has to
> automatically look up the root device and append that to the command line. if
> the user specified a file/device, then that shouldn't happen. we could even
> resort to doing a stat() on the non-options to see if it exists.
.. so because we have no clue about -L we will call stat() for
bad_block_file.
IMHO require absolute paths seems like a better solution :-)
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
http://karelzak.blogspot.com
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
