Mail Archives: opendos/1997/02/17/02:46:53
Once upon a time (on 12 Feb 97 at 23:06) yeep said:
> Allright...who's right?
> You tell me it's software and Mike tells me it's hardware.
> Then I reads this mail from Mike again calling it Firmware.
> Sound all like Vaporware to me.....oh no, that's something else (Micro$oft
> wares == Vaporware)
Just my three cents:
SOFTWARE - BIOS is a software, MBR is a software so it's all SOFTWARE
and Colin (I think) was right:
no limits on partitions (well, almost) - you can have three extended
partitions with other partitions on them. Point. ;-)
> BTW please don't start a
> "4-partition-hard/software-limit-I'm-right-'coz-I'm-smarter-than-you-are-thr
>
> ead" :-)
Oh yeah!? ;=))
=============== OpenDOS - feel the power! http://www.caldera.com ==
From the delequeue to the regiment, a profession in a flash. But
remember Monday signings when from door to door you dash... On the
news the nation mourns you - Unknown Soldier count the cost: for a
second you'll be famous but labeled posthumous... Forgotten Sons...
---
Visit http://ananke.amu.edu.pl/~grendel
t caching removable
> media.
But, in case of mountable partitions/drives, this makes impossible caching of
*any* drive except for the root FS! Better way would be to build into the
mount utility some intelligent code that'd just flush *all* caches before
unmounting the drive. In case of floppies you're on your own though. But I
think that write cache for floppies is, err..., funny idea ;-)
> > 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.
What's wrong with adding some code to flush the cache *inside* the
device driver or, as I wrote above, in the utility (or kernel API) that
unmounts the FS?
> 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.
If I were to chose, I wouldn't want to have automounting enabled. This makes
a case for many errors you cannot help/prevent. Come on, people! Let's not
get that lazy - all you have to do is type (perhaps once only) 'mount
/dev/hdb1 /mnt ex2fs'!! (or sth similar with DOS syntax). I don't knwo how it
is with you, but I don't like too much automagical doodas in the OS - I'd
rather automate it myself with scripts, aliases, batch files - take your
pick.
> > 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.
It's not always stored in sector 0. This sector contains just the OS loader
code which has not commonly defined format (I'm talking about partition BR,
not MBR). You detect, eg. FAT, by first looking up the partition table in the
MBR, then (if one exists) extended partition's partition table, get the
partition code byte and it tells you what *OS* has created the partition. In
case of DOS this tells you at once what type of FS is on the partition in
question (FAT12, FAT16, DOSBIG etc.). Other systems (mostly Unices) use
their superblock to store information about the file system on that partition
(DOS actually does exactly the same) - you have to read the signature from
known spot in the superblock and voila! Linux, for example, has two (AFAIK)
reserved codes to store in the MBR partition table - Linux native (0x80 - I'm
not sure) and swap (0x81 - again, not sure). Then you read the superblock and
read whether it's a minix, ext2fs or other FS.
> 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.
Download the GRUB sources, it detects file systems on the boot time (probably
using technique similar to what I described above). Also look in the Linux
kernel sources for the FS drivers code.
> > _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.
I recently saw a CDR which came with software to mount (in DOS!) an ISO disk
image just like it was another drive. You could copy files from/to the image
using your favorite shell! That's what I call comfort! ;-) Also, I think, 2M
disk formater can mount DDI and NC IMG files as drives. It was a little off
topic, sorry ;-))
> 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).
Mail me with your ideas, we can talk about it.
> If anyone wants to add to the wishlist, please drop me a line.
I just did! Above... ;-))
=============== OpenDOS - feel the power! http://www.caldera.com ==
From the delequeue to the regiment, a profession in a flash. But
remember Monday signings when from door to door you dash... On the
news the nation mourns you - Unknown Soldier count the cost: for a
second you'll be famous but labeled posthumous... Forgotten Sons...
---
Visit http://ananke.amu.edu.pl/~grendel
- Raw text -