Re: fsck files w/relative paths

Mike Frysinger
2013-01-25T19:55:15Z

[-- Attachment #1: Type: Text/Plain, Size: 1836 bytes --]

On Friday 25 January 2013 12:36:23 Karel Zak wrote:
> 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..)

i would highlight the man page says people are supposed to use -- to separate
fsck-specific options from fsck-specific ones.

as to your example here though, that shows that things are also broken. if
you give an absolute path to the bad_block_file, then the auto-silencing of the
root partition is run.

compare:
fsck -L bad_block_file
fsck -L $PWD/bad_block_file

the first will auto-append the root device while the latter will not for no
apparent reason to the user