Re: fsck files w/relative paths

[Karel Zak <kzak@redhat.com>]

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>
 http://karelzak.blogspot.com