[Toybox] New email, [PATCH] fdisk cleanup, etc.

[Isaac]

On Mon, Aug 12, 2013 at 12:57:48PM -0500, Rob Landley wrote:
> On 08/12/2013 12:30:05 AM, Isaac wrote:
<snip>
> >By the way: for extracting CPIO archives, if nlink > 1, check
> >devmajor,
> >devminor, and ino. If they have not been recorded, record and extract;
> >if they have, create a hard link.
> >I'm guessing you'd need something vaguely like this:
> >struct list_members{
> 
> Sigh. I've been meaning to do some variant of a really simple hash
> table or balanced tree. (More likely a tree.) Tar needs hardlink
> checking too, and the way I want to write gene2fs that's an archiver
> as well. (It's a kind of annoying archiver because you need to
> enumerate all the files and work out where you're going to store
> them before you can write the initial metadata; this is why zip
> sticks its metadata on the end, but I never got around to writing a
> "mount -t zip" driver before squashfs went in.)
> 
> Anyway; I'm uncomfortable with an n^2 data storage/lookup mechanism
> on an unbounded data set. Try to cpio a gigabyte directory and it
> could get really slow. (Hmmm... but if it only cares about
> link>1...)

Really, the only important information in the comment is what you need
to watch. Don't bother taking my comments as a guide to *how* it should 
be done; again, I've only got the start of "Using Turbo C", small bits 
of "The C Language", and several years of fixing things that won't build
when I want to install them.

nlink is the number of links to a file, with 1 referring to 1 file, no
hard links. (For testing, cpio -o -H newc |head -n 1 |cut -c 39-46 gives
you nlink.)
So nlink == 1 does not make sense to check.

> >struct list_members *next;
> >struct list_members *prev;
> >int orig_ino; //24 bits saved
> >int nlink; // decrement by 1 on every write matching file?
> >dev_t orig_dev; //devmajor + devminor on newc/"SVR4"
> >long new_ino;
> >dev_t new_dev;
> >}
> >
> >
> >> There was a really fun trick somebody suggested last decade in
> >> busybox, which was to grab the metadata header part of each rpm file
> >> you install and dump it in a directory, then just do the rpm -qpi
> >> code to read what's installed. (So no database, just a directory of
> >> chunks of the files.)
> >
> >I remember seeing that discussion.
> >By the way, this reminds me of Mastodon Linux ("as free of GNUware as
> >is practical with Linux"), xpkg, and makepkg.
> 
> I'm trying to make that quote "100%". Working on it...
> 
> >http://www.mastodon.biz/
> >http://www.pell.portland.or.us/~orc/Code/
> >http://www.pell.portland.or.us/~orc/Code/xrpm/
> >^This is where xpkg/makepkg come from. They can create or extract RPM
> >packages, or at least some version thereof.
> 
> I've been keeping very, very vague tabs on
> https://lwn.net/Articles/441085/
> 
Somewhat interesting.
> 
> That said, rpm does a lot of stuff that I'm not entirely clear on.
> I'm looking at RPM first instead of dpkg first because Red Hat paid
> off the linux foundation's predecessor to put RPM in the LSB (to the
> eternal annoyance of Ubuntu, but what do you _expect_ once you've
> written alien? It's like win-OS/2 guaranteeing nobody would write
> any more OS/2 native software). But unfortunately, LSB doesn't
> specify how to _implement_ a conformant RPM, just says you should
> have one.

http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/pkgformat.html
Probably not adequate.

BTW, in "Real Life", I've seen a bit more .deb packages:
-Steam
-GraphiteOne CAD
-Logger Pro Beta for Linux (in public beta for the last 4 years, I think)

> 
> I'm leaning that way with mail clients, myself...
> 
<snip>
> Oddly, Red Hat 9 from 10 years ago seems to have installed pax by
> default. (I don't have a current fedora, sles, or gentoo set up,
> need to reinstall them when I finish moving to the new laptop, which
> is held up by not wanting to reinstall balsa, not yet finding a
> better email client, and not having worked up the apathy to

sylpheed and claws-mail were the two best GUI mail clients in my book.
Of the two I'd suggest trying sylpheed: the setup actually is organized
in a coherent way.
Of course right now I'm writing this with gvim as editor for mutt,
and I could provide a working config for imap if you wanted.
But despite being faster, it's very much one message at a time.

> reinstall Thunderbird wot done me wrong). And the fact that Ubuntu
> hasn't got pax is less convincing when you realize ubuntu hasn't got
> _patch_ installed by default either. But I have yet to find a Linux
> system that has pax but _not_ tar.