Mail Archives: opendos/1997/02/11/21:54:48
On Tue, 11 Feb 1997, Colin W. Glenn wrote:
> On Tue, 11 Feb 1997 mharris AT blackwidow DOT saultc DOT on DOT ca wrote:
> > On Mon, 10 Feb 1997, Colin W. Glenn wrote:
> >
> > > > > the drive, the system would prompt you to insert the volume if you
> > > > How can you "mount" something that is not there? That is a
> > > As I said, you could 'mount', ie declare the diskname as something you
> > > would like to use later on, the driver should be smart enough to see that
> > > the volume isn't really there and ignore it UNTIL you attempt to access
> >
> > Your definition of "mount" seems to be faulty. To "mount" a
>
> My apologies, I looking for a term which hasn't been declared yet, how
> about we call it INTEND?
Ok, sounds fair. I don't understand the logic behind it though.
You could just make the kernel smart enough to detect what
filesystem is on the disk in the drive, and automount it like it
allready does with FAT disks. Note, that automounting is only
possible for READ-ONLY disks (write protected) and/or disk drives
with write caching disabled. This is the case in DOS right now,
and will always be. The reason is that if the info hasn't been
written to disk yet, and you yank it, then the disk is toasted.
Sure, the kernel could print an error message saying "please put
that disk back in" but this would ONLY work if you complied, and
actually did it. A better solution is not caching removable
media.
> > definition, the drive/disk is NOT mounted anymore. If you
> > haven't unmounted it, then be prepared for errors. As long as
> > write caching isn't enabled on removeable media drives, or the
> > drives are read-only, then it would be possible (and damned
> > useful) for DOS to automount disks from any filesystem type
> > automatically. This however would require the kernel to have
> > some sort of logistics to determine what filesystem is on each
> > disk. I'm not entirely sure if it is possible to detect FS's
> > like this although I suspect it may be for most FS's. At any
> > rate, if you manually mount a disk in a drive, and then pop it
> > out, you will cause problems. Trust me, I've toasted enough
> > floppies with this hard fact.
>
> An application which uses INT 21h 44h 0Dh 60h and the drive is properly
> constructed to utilize command code 1 will cause a fault and should
> generate an error when you change disks. Do this, start a batch file on a
> floppy with a pause statement in it, when you hit the pause, change disks
> and see what command.com does. If command.com was doing raw reads, it
> should crash, but it doesn't because it checks to see it the disk id's as
> the one it was using to begin with.
Well, COMMAND.COM doesn't contain the filesystem code, the kernel
code does, but yes, the kernel does detect disk changes. What
I'm saying is that it would ALSO have to detect different
filesystem types. The other point is what I've stated above,
that drive write caching must be disabled in order to automount
removeable disks.
If this is the case then automounting any FS is possible as long
as the kernel can understand what FS is on the disk to begin
with. Then NO program (MOUNT, INTEND, whatever) is needed at
all. If write caching is enabled, then a MOUNT utility is
needed.
I'm don't fully understand your idea behind this "INTEND"
program. Can you explain it to me in more detail? Is it
something that remembers a magic string or something for each
disk that you have? Then when you want to use the disk it
prompts you to insert it?
IE: INTEND SPECIAL_FLOPPY1 C:\FLOPPY1
Now you've got a different floppy in the A: drive, and your CWD
is C:\ and you type CD FLOPPY1, and get a message saying "Please
insert SPECIAL_FLOPPY1? Is this your intention? If it is, then
it's probably possible, although I doubt it would be very useful.
At least I cant see any immediate uses for it.
> > Also, AFAIK ext2 disks don't have a volume label. I could be
> > wrong however as I'm not that deeply knowledgable on the
>
> As far as I know, _any_ disk reserves the first sector for the media
> information, if not a volume label, then a serial number.
Yes, I'm sure that every disk contains a serial number too, but
what I'm curious about is HOW to detect a particular filesystem's
SIGNATURE in sector 0. Hmmm. This is very interesting.
Do you know how to do it? I'm going to create a bunch of
floppies tonight with different filesystems on them (in Linux)
and examine the boot sectors to see if I can determine unique
signatures. If anyone knows how to do this, then please let me
know. I'll post my results if anyone is interested. This could
be the beginning of a universal automount for OpenDOS.
> > filesystem at that level. I damned well would like to see
> > automounting of ALL removeable media in both DOS, AND Linux
>
> I'd love to be able to access a tape drive as a disk, do a DIR and you get
> the volumes, chdir to a volume, dir, and you get the dir's, keep chdir'ing
> until you see the file you want, then copy it out of the tape drive to
> _whereever_ you want the file to reside. The reason I use a tape drive is
> because I packed a _huge_ directory tree containing my ZIP's, and now I
> have to go through two steps to retrieve a file.
Sure! Why not? Even though I don't have a tape unit, I can see
that as a GREAT benifit to those that do.
Is someone keeping an OpenDOS wishlist together? I'm going to
make one based on my own wishes, and also those of everyone else
in here (an unbiased wishlist that is).
If anyone wants to add to the wishlist, please drop me a line.
TTYL
Mike A. Harris | http://blackwidow.saultc.on.ca/~mharris
Computer Consultant | My webpage has moved and my address has changed.
My dynamic address: http://blackwidow.saultc.on.ca/~mharris/ip-address.html
mailto:mharris AT blackwidow DOT saultc DOT on DOT ca
Want the DR-DOS source code? Visit Caldera's website: www.caldera.com
- Raw text -