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 ?
Indeed the very reason why there is no symlink is because that is a no-op / placeholder command provided by the upstream. Today I've raised a bug about porting the real tool from openSolaris / Illumos operating system: https://bugs.gentoo.org/show_bug.cgi?id=558616 Which is your best bet ^^. Seeing that running the placeholder command won't actually mark the FS as clean = no point.
