Re: fsck files w/relative paths

Karel Zak
2013-01-25T17:36:25Z

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@redhat.com>