fsck files w/relative paths

fsck files w/relative paths

[Mike Frysinger]

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

if i create a dummy local fs in a file:
$ dd if=/dev/zero of=foo count=1 seek=1000
$ mke2fs -F foo

now trying to run fsck on it:
$ fsck ./foo
fsck from util-linux 2.22.2
Usage: fsck.ext4 [-panyrcdfvtDFV] [-b superblock] [-B blocksize]
                [-I inode_buffer_blocks] [-P process_inode_size]
                [-l|-L bad_blocks_file] [-C fd] [-j external_journal]
                [-E extended-options] device

that's weird ...

running it through strace shows it behaves as if no args were provided 
(num_devices=0), so it looks up my rootfs details, and then runs fsck:
[pid 28095] execve("/sbin/fsck.ext4", ["fsck.ext4", "./foo", "/dev/sdd2"], [/* 
69 vars */]) = 0

reading the code, it expects files to have absolute paths.  so running:
$ fsck $PWD/foo
works just fine

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

should we treat all non-options as devices ?  would that break anything ?
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: fsck files w/relative paths

[Karel Zak]

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.

 Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: fsck files w/relative paths

[Mike Frysinger]

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

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 
start with dashes.  are there fscks which use non-options as something other 
than "file/device to check" ?

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.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: fsck files w/relative paths

[Karel Zak]

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

Re: fsck files w/relative paths

[Mike Frysinger]

[-- 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
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]