Re: Can Linux read DMF format floppies?

Jon Katz (jkatz@in.net)
Tue, 20 Aug 1996 09:20:43 -400 (EDT)

Good question... and I, as the guy who wrote the Linux+Win95 mini-HOWTO
should know the answer, but I don't. The thing with DMF is that the ONLY
thing you'd be able to read is the MS-Installation stuff (office, Win95,
NT, etc, etc). DMF doesn't appreciate it when you try to delete things
off the media. The installation files won't delete off of them... (I've been
trying to re-use all the DMF disks that MS sent
me when I was a beta tester. The total is around 100!) but the only way I
can use those disks is to re-format them as 1.44M.

Try mounting a DMF disk on /dev/fd0 and see if it works. Win95/DOS has no
special support for DMF (hence it can't delete or write to the disk, only
read).

There are actually a few different versions of DMF out there (two or
three). This is because the folks at MS changed the format during the
Win95 beta process.

-Jon
jkatz@in.net President and CEO, Internet Consulting by Jon
Voice: +1 317.823.8221 Fax: +1 317.823.8184
9010 Anchor Bay Drive, Indianapolis, IN 46236
Personal: http://www.in.net/~jkatz
Resume: http://www.in.net/~jkatz/I-need-a-job.html
HOW-TO: http://www.in.net/~jkatz/win95/Linux-HOWTO.html
**

On Tue, 20 Aug 1996, Ron Holt wrote:

> Can Linux read DMF format floppies? DMF is Microsoft's "Distribution Media
> Format". Some of the applications they make are distributed in this floppy
> format. I don't know the exact geometry of these floppies. I've been
> told it's something like 21 instead of 18 sectors per track. Does anyone
> know where I can find a spec for DMF?
>
> Thanks,
> Ron
>
> PS. Yes, I've looked at floppy.c in the kernel source...
>
> --
> Ron Holt <ron@caldera.com> Caldera, Inc.
> 
> 
> From owner-linux-kernel-outgoing@vger.rutgers.edu Tue Aug 20 01:22:53 1996
> Received: from wolverine.hq.cic.net by su1.in.net with SMTP (5.65/1.2-eef)
> id AA20607; Tue, 20 Aug 96 01:22:53 -0400
> Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu>
> Received: from vger.rutgers.edu (vger.rutgers.edu [128.6.190.2]) by wolverine.hq.cic.net (8.7.5/jared) with ESMTP id CAA17902; Tue, 20 Aug 1996 02:36:21 -0400
> Received: by vger.rutgers.edu id <105750-22991>; Tue, 20 Aug 1996 02:26:48 -0400
> X-Authentication-Warning: dux.conexio.co.za: mike owned process doing -bs
> Date: Tue, 20 Aug 1996 07:55:57 +0200 (SAT)
> From: Mike Kilburn <mike@conexio.co.za>
> To: Pedro Roque Marques <roque@di.fc.ul.pt>
> Cc: Olaf Titz <olaf@bigred.inka.de>, linux-kernel@vger.rutgers.edu
> Subject: Re: Networking stalls: More details
> In-Reply-To: <199608192138.WAA13335@oberon.di.fc.ul.pt>
> Message-Id: <Pine.LNX.3.95.960820074727.235A-100000@dux.conexio.co.za>
> Mime-Version: 1.0
> Content-Type: TEXT/PLAIN; charset=US-ASCII
> Sender: owner-linux-kernel@vger.rutgers.edu
> Precedence: bulk
>
> >
> > Olaf> I'm skeptical if stacking retransmitting protocols is
> > Olaf> capable of doing more good than harm at all...
> >
>
> This is true when point-point retransmitting protocols are stacked,
> not when end-end protocols are stacked on point-point. For example:
> when reliable PPP (effectively LAP-B) is running thru a modem doing LAP-M.
> The retransmit times are very close and this is where the problem comes
> in. The PPP will retransmit while the LAPM is filling the window (the REJ
> got lost), then LAPM will retransmit. OTOH, end-end protocols have *much*
> larger timeouts so the link level retransmits just looks like a stalled/
> congested link.
>
>
>