Bugzilla Bug 172609

suggest the addition of a soft link
ln -s /usr/bin/udffsck /usr/sbin/fsck.udf

enabling users to fsck /dev/<any_device_with_udf_filesystem>


Reproducible: Always

Steps to Reproduce:
1. fsck /dev/foo 
2.
3.

Actual Results:  
# sudo fsck /dev/foo
fsck 1.39 (29-May-2006)
fsck: fsck.udf: not found
fsck: Error 2 while executing fsck.udf for /dev/foo


Expected Results:  
udffsck runs

Good idea. Any chance you could write an ebuild patch? :)

(In reply to comment #1)
> Good idea. Any chance you could write an ebuild patch? :)
> 

If you have the patience to point me to information on how to do it.  I've
never done any packaging of any kind before.

There's a Gentoo ebuild howto in the developer handbook. To give you more of a
clue, look at the private scripts listing in particular:
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1#doc_chap4

That page also includes general ebuild info. Also the devmanual is very good:
http://devmanual.gentoo.org/

If you aren't familiar with this stuff it probably won't become obvious right
away. If you're an IRC user the #gentoo-dev-help channel on freenode can
probably help you.

If you don't have time then thats fine, just its a nice simple modification so
may be a good starting point for development if you're interested in ebuilds at
all.

(In reply to comment #3)

Yes, I'm interested.  I'll take a look at those references and try to determine
if it's within my grasp.

Need any help here? Maybe you could explain your current understanding of how
this might be fixed and I can fill in some blanks

(In reply to comment #5)
I had looked at some of the documentation you suggested but have been
distracted by other things.

It's a trival enhancement.  The general case seems filesystems having a
check/repair utility create a soft symlink named /usr/bin/fsck.<filesystem>. 
While this may actually be required by some standard that facilitates
automounting, my thought was that this form is easier to remember than
disparate commands for each filesystem.

Since that time, I've looked at these other commands, and it seems they are
somewhat standardized as <filesystem>fsck (e.g. reiserfsck, hfsck).  So I'm not
sure it's even worth the additional complexity of the added symlink.

However, the change I was suggesting is simply the inclusion of an additional
symlink to establish a fsck.udffs (linking to udffsck).  The other reasons this
probably isn't worth it is that not many people mess around with udffs
(although there might be more in the future as dvdrams become popular again),
and it's less likely than most to be an automounted filesystem.

If you do think it's worth doing, the ebuild simply needs to establish that
symlink (ln -sf /usr/bin/udffsck /usr/sbin/fsck.udf).  I would imagine this
would be one of its final tasks.

I completely agree with the added symlink, was wondering if you'd been able to
produce an ebuild patch for it.

I've fixed this in udftools-1.0.0b-r7. The magic line is in src_install():
        dosym /usr/bin/udffsck /usr/sbin/fsck.udf

Thanks!

(In reply to comment #7)
> was wondering if you'd been able to produce an ebuild patch for it.

No.  But I'm still interested in contributing and will look over the materials. 

I've got a patch in mind for yaboot (the ppc bootloader).  It's supposed to be
able to chainload BSD's ppc bootloader, but it doesn't work.  I think I hacked
a sustainable fix on my system that could serve as the basis for a patch.  I
just need to spend some time on the materials you pointed out.

Thanks for the patch.  : )

a few things ...

 - fsck.udf should live in /usr/bin/, not /usr/sbin/
 - this should be pushed upstream so that the default build installs the
symlink

Upstream is dead as a dodo, I tried sending stuff their way before.

Are you 100% on the bin vs sbin thing? On my system:
$ ls /usr/sbin/fsck* /usr/bin/fsck*
ls: cannot access /usr/bin/fsck*: No such file or directory
/usr/sbin/fsck.msdos  /usr/sbin/fsck.udf  /usr/sbin/fsck.vfat

i'm not saying that all fsck binaries belong in /usr/bin/, i'm saying it doesnt
make sense to place the symlink in /usr/sbin/ if the actual prog lives in
/usr/bin/

Not sure if this is still of interest but instead of adding the symlink, it
would have been better to remove the binary udffsck altogether (as most binary
distros do, I believe). The code of udffsck/main.c looks as follows.

int main(int argc, char *argv[])
{
        return 0;
}

Pretty useless to even compile that, is it?

yes and no ... current behavior allows for normal filesystem integration with
fsck related tools/systems ...

as it stands now, i dont see it hurting anything having it exist.  but perhaps
you should pose your questions to the upstream developers and see how they feel
about it ?  seems like a perfectly legitimate question ... why provide the
binary if they dont do anything with it ?