mondo-devel Mailing List for Mondo Rescue

On Sunday 31 March 2002 07:40 am, Hugo Rabson wrote:
> Rejoice, o ye people who requested this feature. :-)

My system has died,
My system has arisen,
My system shall compute again!

Hallejula!

-D

Look at mondo/mondo-restore.c and change the function 'is_file_in_list()' to 
this:-


bool is_file_in_list(char*f, char*list_fname)
{
  char command[MAX_STR_LEN], file[MAX_STR_LEN], tmp[MAX_STR_LEN];
  int i;

  if (strncmp("/mnt/RESTORING", f, 14)==0)
    { strcpy(file, f+14); }
  else
    { strcpy(file, f); }
  if (file[0]=='/' && file[1]=='/')
    {
      strcpy(tmp,file);
      strcpy(file,tmp+1);
    }
  sprintf(tmp,"Checking to see if f=%s, file=%s, is in the list of 
biggiefiles", f, file);
  log_it(tmp);
  sprintf(command,"cat %s | grep -x \"%s\"", list_fname, file);
  if (run_program_and_log_output(command))
    { return(FALSE); }
  else
    { return(TRUE); }
}



See if that helps.

-Hugo

On Sunday 31 March 2002 2:15 pm, Stewart Charnell wrote:
> Hugo,
>
> I did not get any error messages reported by afio. The errors I got were
> of the form:
>
> Reassembling large files
> OK, there are 6 biggiefiles in the archives
> About to think about restoring bigfile 0
>  cat /tmp/tmpfs/biggielist.restore-these | grep -x
> "/mnt/RESTORING//data3/backup/test-backup/Win-nt/sp5/sp5I386.exe"
> --------------------------------end of output------------------------------
> ...ran with errors.
> Skipping /mnt/RESTORING//data3/backup/test-backup/Win-nt/sp5/sp5I386.exe
> (name isn't in biggielist subset)
> .
> .
> .
> About to think about restoring bigfile 5
>  cat /tmp/tmpfs/biggielist.restore-these | grep -x
> "/mnt/RESTORING//data3/backup/test-backup/vcd/test_svcd_pal/test_svcd_pal.b
>in" --------------------------------end of
> output------------------------------ ...ran with errors.
> Skipping
> /mnt/RESTORING//data3/backup/test-backup/vcd/test_svcd_pal/test_svcd_pal.bi
>n (name isn't in biggielist subset)
> About to think about restoring bigfile 6
> ...but its first slice isn't on this CD. Perhaps this was a selective
> restore? There was no bigfile #6. That's OK.
> I'm going to stop restoring bigfiles now.
> Done.
>
> -
> Stewart
>
> On Sunday 31 March 2002 12:39, Hugo Rabson wrote:
> > I backed up a subset of my filesystem a few minutes ago. Then I tried to
> > restore a biggiefile from it. I had a problem with afio (lots of Sig 7's
> > and Sig 11's). I've not seen this before. Does it sound like the problem
> > you're having?
> >
> > I'll run a full backup/restore cycle on the spare PC to see if I get the
> > same problem when I 'nuke'.
> >
> > -Hugo
> >
> > On Friday 29 March 2002 7:56 am, Stewart Charnell wrote:
> > > Hugo,
> > >
> > > Yes this is with a selective restore. I have backed up a complete disk
> > > partition and restored it with the selective restore option and had the
> > > same problem.
> > >
> > > If I run a full restore with a backup of only a single disk partition,
> > > not selecting the disk repartition or reformat options, will the other
> > > disk partitions be left alone?
> > >
> > > -
> > > Stewart
> > >
> > > On Friday 29 March 2002 03:04, Hugo Rabson wrote:
> > > > It looks as if big files aren't being restored to your system when
> > > > you do a selective restore. How about a full restore?
> > > >
> > > > It sounds as if it's something as simple as a missing "tr -s '/' '/'"
> > > > command. We'll see.
> > > >
> > > > -Hugo
> > >
> > > _______________________________________________
> > > Mondo-devel mailing list
> > > Mon...@li...
> > > https://lists.sourceforge.net/lists/listinfo/mondo-devel
> >
> > _______________________________________________
> > Mondo-devel mailing list
> > Mon...@li...
> > https://lists.sourceforge.net/lists/listinfo/mondo-devel

Garf DeLong writes: 

> I just installed mondo-1.41 and mindi-0.59 from source on Redhat 7.2.92 
> (Skipjack -BETA) with the current updates.  It not only compiled and 
> installed, but it also work flawlessly.  I archived to CDRWs without a 
> problem. 
> 
> Thanks for a great program ! 
> 
> Garf

Give me a couple days and I should have an RPM set designed for skipjack.  
Also, I might put out an rpm for the beta that Hugo has released.... 

Hugo, let's talk on monday when I get back about rolling that package k? 

 --
Jesse Keating
j2solutions.net
Mondo Support Team

Mondo v1.42 (beta) allows you to run mondorestore without booting from 
floppy/CD first. It doesn't work for ISO's or NFS backups yet but it does 
work for CD- and tape-based backups. It lets you selectively restore files to 
your live filesystem.

Rejoice, o ye people who requested this feature. :-)

-Hugo

Hugo,

I did a little testing with full vs. partial restores of a backup of 
sub-directories within a partition.

Partial restore - big files not restored.
Full restore   - big files restored.

Specifically selecting a single big file to restore (toggle restore file list 
setting to '*') resulted in all files under the root directory being restored
except the bigfiles.

-
Stewart

On Friday 29 March 2002 03:04, Hugo Rabson wrote:
> It looks as if big files aren't being restored to your system when you do a
> selective restore. How about a full restore?
>
> It sounds as if it's something as simple as a missing "tr -s '/' '/'"
> command. We'll see.
>
> -Hugo
>
>
> ------obligatory signature------
> http://www.microwerks.net/~hugo
> -----end of obligatory sig.-----
>
> --- Stewart Charnell <st...@ch...> wrote:
> >I am finding that I am unable to restore 'biggiefiles' (files considered
> > by mondoarchive to be large files needing to be split up before writing
> > to the archive) from mondo archives. While all other files are restored
> > none of the 'biggiefiles' are. Is anyone else finding this problem?
> >
> >The archive compares with no problems reported. I have had this problem
> > with both mondo-1.40-7 and mondo-1.41-1.
> >
> >I created a test directory containing  a mixture of small files and large
> >files which fit on a single mondoarchive for my tests.
> >
> >I am running Suse7.2.
> >
> >The section of the restore log which looks relavent is:
> >
> >Reassembling large files
> >OK, there are 6 biggiefiles in the archives
> >About to think about restoring bigfile 0
> > cat /tmp/tmpfs/biggielist.restore-these | grep -x
> >"/mnt/RESTORING//data3/backup/test-backup/Win-nt/sp5/sp5I386.exe"
> >--------------------------------end of
> > output------------------------------ ...ran with errors.
> >Skipping /mnt/RESTORING//data3/backup/test-backup/Win-nt/sp5/sp5I386.exe
> >(name isn't in biggielist subset)
> >
> >I think the '/mnt/RESTORING/' section of the file pathname is the source
> > of the problem as the biggielist.restore-these file does not contain this
> > part of the pathname. I don't know enough about the source code to be
> > sure of this or to attempt a patch.
> >
> >I have forwarded a full copy of the mondo-restore.log file to Hugo.
> >
> >-
> >Stewart Charnell

Hugo,

I did not get any error messages reported by afio. The errors I got were
of the form:

Reassembling large files
OK, there are 6 biggiefiles in the archives
About to think about restoring bigfile 0
 cat /tmp/tmpfs/biggielist.restore-these | grep -x 
"/mnt/RESTORING//data3/backup/test-backup/Win-nt/sp5/sp5I386.exe"
--------------------------------end of output------------------------------
...ran with errors.
Skipping /mnt/RESTORING//data3/backup/test-backup/Win-nt/sp5/sp5I386.exe 
(name isn't in biggielist subset)
.
.
.
About to think about restoring bigfile 5
 cat /tmp/tmpfs/biggielist.restore-these | grep -x 
"/mnt/RESTORING//data3/backup/test-backup/vcd/test_svcd_pal/test_svcd_pal.bin"
--------------------------------end of output------------------------------
...ran with errors.
Skipping 
/mnt/RESTORING//data3/backup/test-backup/vcd/test_svcd_pal/test_svcd_pal.bin 
(name isn't in biggielist subset)
About to think about restoring bigfile 6
...but its first slice isn't on this CD. Perhaps this was a selective restore?
There was no bigfile #6. That's OK.
I'm going to stop restoring bigfiles now.
Done.

-
Stewart

On Sunday 31 March 2002 12:39, Hugo Rabson wrote:
> I backed up a subset of my filesystem a few minutes ago. Then I tried to
> restore a biggiefile from it. I had a problem with afio (lots of Sig 7's
> and Sig 11's). I've not seen this before. Does it sound like the problem
> you're having?
>
> I'll run a full backup/restore cycle on the spare PC to see if I get the
> same problem when I 'nuke'.
>
> -Hugo
>
> On Friday 29 March 2002 7:56 am, Stewart Charnell wrote:
> > Hugo,
> >
> > Yes this is with a selective restore. I have backed up a complete disk
> > partition and restored it with the selective restore option and had the
> > same problem.
> >
> > If I run a full restore with a backup of only a single disk partition,
> > not selecting the disk repartition or reformat options, will the other
> > disk partitions be left alone?
> >
> > -
> > Stewart
> >
> > On Friday 29 March 2002 03:04, Hugo Rabson wrote:
> > > It looks as if big files aren't being restored to your system when you
> > > do a selective restore. How about a full restore?
> > >
> > > It sounds as if it's something as simple as a missing "tr -s '/' '/'"
> > > command. We'll see.
> > >
> > > -Hugo
> >
> > _______________________________________________
> > Mondo-devel mailing list
> > Mon...@li...
> > https://lists.sourceforge.net/lists/listinfo/mondo-devel
>
> _______________________________________________
> Mondo-devel mailing list
> Mon...@li...
> https://lists.sourceforge.net/lists/listinfo/mondo-devel

I backed up a subset of my filesystem a few minutes ago. Then I tried to 
restore a biggiefile from it. I had a problem with afio (lots of Sig 7's and 
Sig 11's). I've not seen this before. Does it sound like the problem you're 
having?

I'll run a full backup/restore cycle on the spare PC to see if I get the same 
problem when I 'nuke'.

-Hugo


On Friday 29 March 2002 7:56 am, Stewart Charnell wrote:
> Hugo,
>
> Yes this is with a selective restore. I have backed up a complete disk
> partition and restored it with the selective restore option and had the
> same problem.
>
> If I run a full restore with a backup of only a single disk partition, not
> selecting the disk repartition or reformat options, will the other disk
> partitions be left alone?
>
> -
> Stewart
>
> On Friday 29 March 2002 03:04, Hugo Rabson wrote:
> > It looks as if big files aren't being restored to your system when you do
> > a selective restore. How about a full restore?
> >
> > It sounds as if it's something as simple as a missing "tr -s '/' '/'"
> > command. We'll see.
> >
> > -Hugo
>
> _______________________________________________
> Mondo-devel mailing list
> Mon...@li...
> https://lists.sourceforge.net/lists/listinfo/mondo-devel

On Sunday 31 March 2002 11:48 am, Stewart Charnell wrote:
> If I have a mondo backup of a few directories within a disk partition will
> an interactive restore of everything on the backup delete the partition
> contents before restoring or just restore the files from the backup?

An interactive restore will only delete files as part of the 
partitioning/formatting function. If you do not partition or format your 
drives then you will not delete any data _unless_ you backed up a partition 
with the -x (image) switch. In that case, you will overwrite the partition 
with the backup. Otherwise, with regular ext2/ext3/ReiserFS/XFS/JFS 
partitions, you'll simply be overwriting existing files (or replacing lost 
ones). You won't delete anything.

> Similarly the backups have directory entries corresponding to all the disk
> partitions even though I may have only backed up files from a single
> partition. In this case would an interactive 'restore everything' just
> recover the files from the backed up partition and leave the other
> partitions intact?

Say no when asked if you want to restore everything. Say yes when asked if 
you want to restore some files. Then, select the directories you want to 
restore. Problem solved. :)

-Hugo

If I have a mondo backup of a few directories within a disk partition will an 
interactive restore of everything on the backup delete the partition contents 
before restoring or just restore the files from the backup?

Similarly the backups have directory entries corresponding to all the disk 
partitions even though I may have only backed up files from a single 
partition. In this case would an interactive 'restore everything' just 
recover the files from the backed up partition and leave the other partitions 
intact?

I think I am asking will an interactive 'restore everything' delete any data 
from disk partitions before the restore or just overwrite existing data (if 
present) with the corresponding data from the backup.

-
Stewart

Are tape users having any problems with Mondo v1.41? I'm conducting some 
tests on the selective restore function and I'm getting some very odd 
messages from afio - sig 7 and sig 11, mostly. Odd.

-Hugo

I just installed mondo-1.41 and mindi-0.59 from source on Redhat 7.2.92=20
(Skipjack -BETA) with the current updates.  It not only compiled and=20
installed, but it also work flawlessly.  I archived to CDRWs without a=20
problem.

Thanks for a great program !

Garf

On Saturday 30 March 2002 10:28 pm, eri...@pr... wrote:
> The second back-up restored completed (i.e., it overwrote the disk) but
> complained afterwards that the lilo options lib32 and linear conflicted
> and that lilo did not run successfully. Afterwards, I was unable to boot
> the system.

Thanks for your other comments, btw. They were very helpful.

FYI, you can run LILO manually if you want. Just type:-

# mount-me
# chroot /mnt/RESTORING lilo
# unmount-me

-Hugo

On Sat, 30 Mar 2002 eri...@pr... wrote:
> On Sat, 30 Mar 2002 eri...@pr... wrote:
> > Where can I find the instructions to recover *selected* files from the 
> > mondo CD?
> 
> To answer my own question: Instructions can be found by following the 
> links from the "Software Download" page.

Whew - I was able to restore the files that I selected!!!

The documentation, though, is slightly inaccurate: There's no mention of 
the partition dialogue. (That's intimidating when you're only restoring a 
few files.)

-- 
Eric P.
Los Gatos, CA

On Sat, 30 Mar 2002 eri...@pr... wrote:
> Where can I find the instructions to recover *selected* files from the 
> mondo CD?

To answer my own question: Instructions can be found by following the 
links from the "Software Download" page.

-- 
Eric P.
Los Gatos, CA

I'm using Mondo 1.40-3 (installed from an rpm) on an updated version of RH
7.1 (i.e., all errata/patches up to March 8 have been applied to the
system before running mondoarchive). e.g.,

	filesystem-2.1.0
	e2fsprogs-1.23
	gcc-2.96
	gcc-c++-2.96
	glibc-2.2.4
	glibc-common-2.2.4
	initscripts-5.84.1
	libstdc++-2.96
	mkinitrd-3.2.6
	SysVinit-2.78

The first back-up died [before restoring] after complaining about a
missing .so file. (Sorry - I didn't catch that one.)

The second back-up restored completed (i.e., it overwrote the disk) but
complained afterwards that the lilo options lib32 and linear conflicted
and that lilo did not run successfully. Afterwards, I was unable to boot
the system.

I reinstalled RH 7.1 *from scratch* and updated all the rpm's but still
need to recover the files that [I believed that] mondo had archived but
there doesn't appear to be a mondorestore man page [yet]. Where can I find
the instructions to recover *selected* files from the mondo CD?

-- 
Eric P.
Los Gatos, CA

"Hypocrisy (or lunacy - take your pick) is coming from those who insist that 
politically correct tools should be preferred even when they clearly suck."
- Al Viro, LKML, 03/25/2002 (approx.), re: BitKeeper

Hey, if I re-release Mondo under Microsoft's Shared Source license, how long 
will it be before someone calls the INS & tells them there's a British 
drug-runner heading for Houston airport via London Gatwick? :^)

-Hugo

On Fri, 2002-03-29 at 11:00, Kendric Beachey wrote:
> 1440KB = 1440 * 1 kilobyte
>        = 1440 * 1024 bytes
>        = 1474560 bytes
> 1.44MB = 1.44 * 1 megabyte
>        = 1.44 * 1048576 bytes
>        = 1509949.44 bytes
>        = 1474.56KB
>        != 1440KB
> The "standard" capacity of a so-called 1.44MB diskette is 1474560 bytes.

Because of this "confusion," in 1998, the IEC adopted a new prefix
convention known as "binary-multiple prefix" to complement the common
"SI/decimal prefix" conventions.  The latter works on instances of 10^3
whereas the former now works on instances of 2^10.  The IEEE and NIST
have temporarily adopted them as well, pending either a replacement or
approval as an official standard.

You can read more about them here:
http://physics.nist.gov/cuu/Units/binary.html

As such, binary/SI prefix "accurate," it is a 1440KiB/1480KB floppy, or
a 1.41MiB/1.48MB, using 3 significant digits for each.  Yes, this is
somewhat confusing, but that is largely due to the fact that some people
use instances of 10^3 SI/decimal and others use 2^10 binary for
prefixes.  The idea is that the legacy SI/decimal prefixes _continue_ to
mean 10^3/decimal and *NOT* 2^10/binary, which now have their own, new
prefix nomenclature.

-- Bryan

-- 
"We don't treat Linux as a toy.  We've got real business problems
 problems that we need to solve." -- Credit Suisse First Boston
 c/o 2002Mar27 Forbes article on 100% Linux move by Merrill Lynch
-----------------------------------------------------------------
Bryan J. Smith, SmithConcepts, Inc.     mailto:b.j...@ie...
Engineers and IT Professionals       http://www.SmithConcepts.com

On Fri, 29 Mar 2002 15:36:11 -0600
"bruce@hotmail" <bn...@ho...> issued forth:

> I tried the most recent on MDK 8.2 with Nvidia drivers compiled into the

Most recent as in not the one that was included with MDK?  The one that was
included with MDK seems to have issues, and since we never knew they would
include it, it was kinda hard for us to prepare for it... *rolleyes*

-- 
Jesse Keating
j2solutions.net
Mondo Support

"Fatal error. Cannot loopmount /tmp/mindilinux/5363/temp.rd to 
/tmp/mindilinux/5363/mnt1"

Odd. Does your kernel support loopmounting?

-Hugo


On Friday 29 March 2002 9:36 pm, you wrote:
>  Hugo and company,
>
>  I tried the most recent on MDK 8.2 with Nvidia drivers compiled into the
> kernel (I doubt that matters, but that's the only real change to the
> pristine MDK installed kernel)

 Hugo and company,

 I tried the most recent on MDK 8.2 with Nvidia drivers compiled into the
kernel (I doubt that matters, but that's the only real change to the
pristine MDK installed kernel)

 first note.  mondo/mindi looks for the mount on the Cdrom even if it's not
going to be used (I'm supposed to be writing my ISO's to a mounted
partition)  After I unmounted the CDROM, it started OK.

 Things still died after mindi tried making the boot disk.

 Here are my mondo script and log files.

 I was logged on as root with nothing running (I no longer automatically use
X as my log on menu)

 Bruce

On Fri, 29 Mar 2002 10:41:23 +0000
"ff...@au..." <ff...@au...> issued forth:

> Mindi uses fdformat if it exists, otherwise superformat.  Unfortunately
> it passes /dev/fd0 as the target, and this won't work with earlier
> versions of fdformat.  Upgrade util-linux to the latest version.
> This worked for me.

I'm not quite sure I follow this.  What would it use BESIDES /dev/fd0 ?  For
the first img, it should be formatted to /dev/fd0u1722 anyway...

-- 
Jesse Keating
j2solutions.net

>I don't recall whether Mindi uses superformat by default or fdformat. It
>uses one if it can. If it can't, it uses the other.
>
>To find out which is the default, I would have to read the source code. Of
>course, my source code is incredibly hard to read & understand, so I don't
>ever attempt to read it. ;)
>
>-Hugo

Mindi uses fdformat if it exists, otherwise superformat.  Unfortunately
it passes /dev/fd0 as the target, and this won't work with earlier
versions of fdformat.  Upgrade util-linux to the latest version.
This worked for me.

Douglas

I don't recall whether Mindi uses superformat by default or fdformat. It uses one if it can. If it can't, it uses the other.

To find out which is the default, I would have to read the source code. Of course, my source code is incredibly hard to read & understand, so I don't ever attempt to read it. ;)

-Hugo

------obligatory signature------
http://www.microwerks.net/~hugo
-----end of obligatory sig.-----


--- "James D. Freels" <jdf...@co...> wrote:
>Since this is a mondo-devel mailing list, why not answer this question by 
>looking at the ~/images/mindi directory after a mindi/mondo run:
>
>total 24421
>drwxr-xr-x    2 root     root          304 Mar 29 11:14 .
>-rw-r--r--    1 root     root      1474560 Mar 29 11:14 mindi-data-2.img
>-rw-r--r--    1 root     root      1474560 Mar 29 11:14 mindi-data-1.img
>-rw-r--r--    1 root     root      1763328 Mar 29 11:14 mindi-boot.1722.img
>-rw-r--r--    1 root     root      2949120 Mar 29 11:14 mindi-boot.2880.img
>
>My original question still stands: is mondo-archive using superformat?  If 
>so, it has a bug since "superformat /dev/fd0u1722" does not work.
>
>On Friday 29 March 2002 11:00, Kendric Beachey wrote:
>> On Friday, 29 March 2002 06:38, Bryan J. Smith wrote:
>> > There are two common ways to "extend" the 1.44MB floppy disk.
>> > One is number of sectors per track, from 18 to 21.
>> > Another is the number of tracks per disk, from 80 to 82.
>> >
>> > Doing the first yields 1.680MB.  Doing both yields 1.722MB.
>>
>> I learned late in life that the designation "1.44MB" is actually a
>> misnomer, having been some less-than-precise person's paraphrasing of
>> "1440KB" that was picked up somewhere along the way.
>>
>> 1440KB = 1440 * 1 kilobyte
>>        = 1440 * 1024 bytes
>>        = 1474560 bytes
>>
>> 1.44MB = 1.44 * 1 megabyte
>>        = 1.44 * 1048576 bytes
>>        = 1509949.44 bytes
>>        = 1474.56KB
>>        != 1440KB
>>
>> The "standard" capacity of a so-called 1.44MB diskette is 1474560 bytes.
>>
>> So, not having any superformatted diskettes on hand, and not having any
>> diskettes nearby that I can ruin, can anyone confirm the actual capacity in
>> bytes of the two superformats?
>
>-- 
>James D. Freels, P.E._i, Ph.D.
>jdf...@co...  or  fre...@or...
>mpg123 http://scastsrv2.shoutcast.com:8048/
>
>_______________________________________________
>Mondo-devel mailing list
>Mon...@li...
>https://lists.sourceforge.net/lists/listinfo/mondo-devel

_____________________________________________________________
Want a new web-based email account ? ---> http://www.firstlinux.net

_____________________________________________________________
Run a small business? Then you need professional email like yo...@yo... from Everyone.net  http://www.everyone.net?tag

Since this is a mondo-devel mailing list, why not answer this question by 
looking at the ~/images/mindi directory after a mindi/mondo run:

total 24421
drwxr-xr-x    2 root     root          304 Mar 29 11:14 .
-rw-r--r--    1 root     root      1474560 Mar 29 11:14 mindi-data-2.img
-rw-r--r--    1 root     root      1474560 Mar 29 11:14 mindi-data-1.img
-rw-r--r--    1 root     root      1763328 Mar 29 11:14 mindi-boot.1722.img
-rw-r--r--    1 root     root      2949120 Mar 29 11:14 mindi-boot.2880.img

My original question still stands: is mondo-archive using superformat?  If 
so, it has a bug since "superformat /dev/fd0u1722" does not work.

On Friday 29 March 2002 11:00, Kendric Beachey wrote:
> On Friday, 29 March 2002 06:38, Bryan J. Smith wrote:
> > There are two common ways to "extend" the 1.44MB floppy disk.
> > One is number of sectors per track, from 18 to 21.
> > Another is the number of tracks per disk, from 80 to 82.
> >
> > Doing the first yields 1.680MB.  Doing both yields 1.722MB.
>
> I learned late in life that the designation "1.44MB" is actually a
> misnomer, having been some less-than-precise person's paraphrasing of
> "1440KB" that was picked up somewhere along the way.
>
> 1440KB = 1440 * 1 kilobyte
>        = 1440 * 1024 bytes
>        = 1474560 bytes
>
> 1.44MB = 1.44 * 1 megabyte
>        = 1.44 * 1048576 bytes
>        = 1509949.44 bytes
>        = 1474.56KB
>        != 1440KB
>
> The "standard" capacity of a so-called 1.44MB diskette is 1474560 bytes.
>
> So, not having any superformatted diskettes on hand, and not having any
> diskettes nearby that I can ruin, can anyone confirm the actual capacity in
> bytes of the two superformats?

-- 
James D. Freels, P.E._i, Ph.D.
jdf...@co...  or  fre...@or...
mpg123 http://scastsrv2.shoutcast.com:8048/

On Friday, 29 March 2002 06:38, Bryan J. Smith wrote:
> There are two common ways to "extend" the 1.44MB floppy disk.
> One is number of sectors per track, from 18 to 21.
> Another is the number of tracks per disk, from 80 to 82.
:
> Doing the first yields 1.680MB.  Doing both yields 1.722MB.

I learned late in life that the designation "1.44MB" is actually a misnomer, 
having been some less-than-precise person's paraphrasing of "1440KB" that was 
picked up somewhere along the way.

1440KB = 1440 * 1 kilobyte
       = 1440 * 1024 bytes
       = 1474560 bytes

1.44MB = 1.44 * 1 megabyte
       = 1.44 * 1048576 bytes
       = 1509949.44 bytes
       = 1474.56KB
       != 1440KB

The "standard" capacity of a so-called 1.44MB diskette is 1474560 bytes.

So, not having any superformatted diskettes on hand, and not having any 
diskettes nearby that I can ruin, can anyone confirm the actual capacity in 
bytes of the two superformats?

-- 
Kendric Beachey
ak...@kc...

DVD decryption in seven lines of Perl code:
$_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map{$_%16or$t^=$c^=( 
$m=(11,10,116,100,11,122,20,100)[$_/16%8])&110;$t^=(72,@z=(64,72,$a^=12*($_%16 
-2?0:$m&17)),$b^=$_%64?12:0,@z)[$_%8]}(16..271);if((@a=unx"C*",$_)[20]&48){$h 
=5;$_=unxb24,join"",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$ 
d=unxV,xb25,$_;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d8^($f=$t&($d12^$d4^ 
$d^$d/8))<<17,$e=$e8^($t&($g=($q=$e14&7^$e)^$q*8^$q<<6))<<9,$_=$t[$_]^ 
(($h=8)+=$f+(~$g&$t))for@a[128..$#a]}print+x"C*",@a}';s/x/pack+/g;eval