guess_fstype?
I have a patch that will make use of volume_id/* filesystem detection code to compile as a standalone guess_fstype._________________Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread

that is one of the ones I patch for busybox before, but since then they have changed a few things and I patched in support for new filesystems as did some other, so it needs to be redone - note that busybox already has blkid which does the same thing if configured, but is much slower because it does a read for each fs type instead of a single batch of sequential reads using a union of structs (excellent fast technique to use for guessing mime types too if someone had the time)_________________Web Programming - Pet Packaging 100 & 101

losetup should be patched to be able to use it as losetup-FULL .
ash should have ASH_ARGV and ASH_ARGC for to show in set output .

klibc-2.0.1/usr/kinit/fstype could be merged into guess_fstype .

I remember that you ported some kind of media player.
Perhaps start ffplay if dropping to initial ramdisk console as lollypop for new users Would make the initrd.lz bigger . SneekyLinux videos come in mind.

losetup should be patched to be able to use it as losetup-FULL .
ash should have ASH_ARGV and ASH_ARGC for to show in set output .

klibc-2.0.1/usr/kinit/fstype could be merged into guess_fstype .

I remember that you ported some kind of media player.
Perhaps start ffplay if dropping to initial ramdisk console as lollypop for new users Would make the initrd.lz bigger . SneekyLinux videos come in mind.

argc == $#
argv == $@
argv[1] == $1 ...

that was minimp3, but I'd like to do something with stb_vorbis to play ogg files

in other words it should support arrays - it has been a requested feature for a while, I think Rob Landley has it stubbed out in the toybox shell. I use set to store an array as $@
for example
set --
set -- $@ `find .`
#now I have an "array" of all files/directories in the pwd
#downside is that it is only 1 at a time

For guess_fstype i am thinking of trying to use klibc fstype.c and main.c instead of that Puppy one ( cleaner, easier to work with )

I was looking for this initially in klibc before I worked on busybox patch but somehow I missed it.
But now that you pointed this out to me, I see that it is missing important filesystems: fat, ntfs, udf, etc.

Attached is a patch that will make bb_guess_fstype (which can be renamed to guess_fstype) from plain vanilla busybox 1.21. Included in the patch is f2fs probe.

How to use:
1. Extract vanilla busybox 1.21 source
2. Apply the patch (gunzip first)
3. Go to the volume-id directory
4. Type "make"
5. You will end-up with a bb_guess_fstype which can be renamed to guess_fstype for proper use.

You can fine-tune which probes to be included by editing fake_libbb.h (removing the defines) as well as the Makefile (removing unused object code from being linked in).
From here to busybox applet shouldn't be too difficult, I suppose.

I bet Denys would accept it as a replacement for blkid if we added UUID and label - they are just at different offsets and most seem to already be documented in the source already._________________Web Programming - Pet Packaging 100 & 101

I bet Denys would accept it as a replacement for blkid if we added UUID and label - they are just at different offsets and most seem to already be documented in the source already.

I'm not so sure, I thought that's what blkid is for. The code in volume_id is actually meant for blkid, and in all the filesystem probes they actually stores both the label and the UUID if available (in fact, some of the unused probes seem to work right but they don't have UUID and labels identified properly and my guess is that why Denys left them out atm). I would be happy to drop guess_fstype altogether if only busybox blkid can specify which device to probe (instead of probing all) - but alas they are not.

Anyway, as it is now, busybox guess_fstype takes 2.5 times the time of the original guess_fstype , but I'll take use it anyway because it is still in milliseconds range and it is more maintainable. I am re-posting the patch because the original one I posted was buggy (forgot to return pointer value in xzalloc - but it worked previously as long as I didn't turn on optimisation ...).

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum