|
|
|
|
|
|
| Author |
Message |
Christoph Hellwig
*nix forums beginner
Joined: 08 May 2002
Posts: 40
|
 Posted: Mon Jul 10, 2006 8:22 pm Post subject:
Re: [RFC] mount can figure out fstype automatically
|
|
|
On Mon, Jul 10, 2006 at 01:06:02PM -0600, Scott Long wrote:
| Quote: | So in your opinion and experience, what are the pros and cons of
maintaining a table of magic numbers?
|
The feature is imensely useful. The implementation won't win any
points for a clean design but works very well in practice. I think
it's definitly better than probing in the kernel because letting a filesystem
driver try to make sense of something that's not it's own format can
lead to all kinds of funnies. Linux does this (iterating all filesystem
types in kernel) for the special case of the root filesystem where mount(
is not available, and it showeds various interesting bugs at least in the
fat driver.
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
 |
Scott Long
*nix forums Guru Wannabe
Joined: 16 Jun 2002
Posts: 167
|
| Posted: Mon Jul 10, 2006 8:30 pm Post subject:
Re: [RFC] mount can figure out fstype automatically
|
|
|
Christoph Hellwig wrote:
| Quote: | On Mon, Jul 10, 2006 at 01:06:02PM -0600, Scott Long wrote:
So in your opinion and experience, what are the pros and cons of
maintaining a table of magic numbers?
The feature is imensely useful. The implementation won't win any
points for a clean design but works very well in practice. I think
it's definitly better than probing in the kernel because letting a filesystem
driver try to make sense of something that's not it's own format can
lead to all kinds of funnies. Linux does this (iterating all filesystem
types in kernel) for the special case of the root filesystem where mount(
is not available, and it showeds various interesting bugs at least in the
fat driver.
|
How does it resolve situations like with UDF vs iso9660, where both
structures can co-exist?
Scott
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Christoph Hellwig
*nix forums beginner
Joined: 08 May 2002
Posts: 40
|
| Posted: Mon Jul 10, 2006 8:39 pm Post subject:
Re: [RFC] mount can figure out fstype automatically
|
|
|
On Mon, Jul 10, 2006 at 02:30:20PM -0600, Scott Long wrote:
| Quote: | lead to all kinds of funnies. Linux does this (iterating all filesystem
types in kernel) for the special case of the root filesystem where mount(
is not available, and it showeds various interesting bugs at least in the
fat driver.
How does it resolve situations like with UDF vs iso9660, where both
structures can co-exist?
|
The kernel doesn't do anything fancy. It just walks the list of filesystem
and the first fs that takes it gets it. To answer the specific example
iso9660 is registered before udf so if you wanted to use a dual-fs cdrom
as root you would get iso9600 unless you specified the rootfstype=udf
boot option.
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
David O'Brien
*nix forums beginner
Joined: 16 May 2003
Posts: 26
|
| Posted: Mon Jul 10, 2006 10:38 pm Post subject:
Re: [RFC] mount can figure out fstype automatically
|
|
|
On Sat, Jul 08, 2006 at 12:17:19PM -0400, Craig Rodrigues wrote:
| Quote: | I was thinking of doing something like that. You can basically
get the same info by doing something like:
file - < /dev/ad0s1e
/dev/stdin: Unix Fast File system (little-endian)
file - < /dev/ad0s4
/dev/stdin: SGI XFS filesystem
I leaned away from this approach in mount( because:
- I didn't want to tie mount( to file(1)
|
Why not? We have libmagic for purposes like this.
--
-- David (obrien@FreeBSD.org)
Q: Because it reverses the logical flow of conversation.
A: Why is top-posting (putting a reply at the top of the message) frowned upon?
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Scott Long
*nix forums Guru Wannabe
Joined: 16 Jun 2002
Posts: 167
|
| Posted: Tue Jul 11, 2006 12:39 am Post subject:
Re: [RFC] mount can figure out fstype automatically
|
|
|
David O'Brien wrote:
| Quote: | On Sat, Jul 08, 2006 at 12:17:19PM -0400, Craig Rodrigues wrote:
I was thinking of doing something like that. You can basically
get the same info by doing something like:
file - < /dev/ad0s1e
/dev/stdin: Unix Fast File system (little-endian)
file - < /dev/ad0s4
/dev/stdin: SGI XFS filesystem
I leaned away from this approach in mount( because:
- I didn't want to tie mount( to file(1)
Why not? We have libmagic for purposes like this.
|
This is an interesting idea. However, it has the potential to
add a dependency on /usr to the early boot environment. Maybe it
could be done via rtld?
Scott
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Maxim Sobolev
*nix forums beginner
Joined: 03 Sep 2002
Posts: 18
|
| Posted: Tue Jul 11, 2006 1:05 am Post subject:
Re: [RFC] mount can figure out fstype automatically
|
|
|
Scott Long wrote:
| Quote: | David O'Brien wrote:
On Sat, Jul 08, 2006 at 12:17:19PM -0400, Craig Rodrigues wrote:
I was thinking of doing something like that. You can basically
get the same info by doing something like:
file - < /dev/ad0s1e
/dev/stdin: Unix Fast File system (little-endian)
file - < /dev/ad0s4
/dev/stdin: SGI XFS filesystem
I leaned away from this approach in mount( because:
- I didn't want to tie mount( to file(1)
Why not? We have libmagic for purposes like this.
This is an interesting idea. However, it has the potential to
add a dependency on /usr to the early boot environment. Maybe it
could be done via rtld?
|
Well, we have dynamic /sbin now, so that it's only the matter of moving
libmagic into /lib.
-Maxim
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Scott Long
*nix forums Guru Wannabe
Joined: 16 Jun 2002
Posts: 167
|
| Posted: Tue Jul 11, 2006 1:23 am Post subject:
Re: [RFC] mount can figure out fstype automatically
|
|
|
Maxim Sobolev wrote:
| Quote: | Scott Long wrote:
David O'Brien wrote:
On Sat, Jul 08, 2006 at 12:17:19PM -0400, Craig Rodrigues wrote:
I was thinking of doing something like that. You can basically
get the same info by doing something like:
file - < /dev/ad0s1e
/dev/stdin: Unix Fast File system (little-endian)
file - < /dev/ad0s4
/dev/stdin: SGI XFS filesystem
I leaned away from this approach in mount( because:
- I didn't want to tie mount( to file(1)
Why not? We have libmagic for purposes like this.
This is an interesting idea. However, it has the potential to
add a dependency on /usr to the early boot environment. Maybe it
could be done via rtld?
Well, we have dynamic /sbin now, so that it's only the matter of moving
libmagic into /lib.
-Maxim
|
libmagic depends on libz. Let's not go down the path of populating
/lib with every convenience under the sun.
Scott
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Danny Braniss
*nix forums beginner
Joined: 11 Jul 2006
Posts: 1
|
| Posted: Tue Jul 11, 2006 5:14 am Post subject:
Re: [RFC] mount can figure out fstype automatically
|
|
|
| Quote: | Maxim Sobolev wrote:
Scott Long wrote:
David O'Brien wrote:
On Sat, Jul 08, 2006 at 12:17:19PM -0400, Craig Rodrigues wrote:
I was thinking of doing something like that. You can basically
get the same info by doing something like:
file - < /dev/ad0s1e
/dev/stdin: Unix Fast File system (little-endian)
file - < /dev/ad0s4
/dev/stdin: SGI XFS filesystem
I leaned away from this approach in mount( because:
- I didn't want to tie mount( to file(1)
Why not? We have libmagic for purposes like this.
This is an interesting idea. However, it has the potential to
add a dependency on /usr to the early boot environment. Maybe it
could be done via rtld?
Well, we have dynamic /sbin now, so that it's only the matter of moving
libmagic into /lib.
-Maxim
libmagic depends on libz. Let's not go down the path of populating
/lib with every convenience under the sun.
and |
/usr/share/misc/magic
btw, the idea of mount figuring out the nount-type has allot of merit,
but using a 10 ton hammer is not the way.
danny
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Robert Watson
*nix forums Guru Wannabe
Joined: 22 Mar 2002
Posts: 218
|
| Posted: Tue Jul 11, 2006 11:45 am Post subject:
Re: [RFC] mount can figure out fstype automatically
|
|
|
On Mon, 10 Jul 2006, Christoph Hellwig wrote:
| Quote: | On Mon, Jul 10, 2006 at 01:06:02PM -0600, Scott Long wrote:
So in your opinion and experience, what are the pros and cons of
maintaining a table of magic numbers?
The feature is imensely useful. The implementation won't win any points for
a clean design but works very well in practice. I think it's definitly
better than probing in the kernel because letting a filesystem driver try to
make sense of something that's not it's own format can lead to all kinds of
funnies. Linux does this (iterating all filesystem types in kernel) for the
special case of the root filesystem where mount( is not available, and it
showeds various interesting bugs at least in the fat driver.
|
In both FreeBSD and Darwin, I've noticed that the kernel msdosfs code is
excessively permissive as to what it considers a FAT file system. This is
presumably necessary due to the enourmous diversity of FAT file systems
floating around, but it makes it a little too easy to cause msdos to trip over
layouts that violate its layout assumptions.  FAT is much more reliably
detected by looking at the partition type it lives in than by looking at the
bytes that appear inside the partition, I believe.
Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Ceri Davies
*nix forums addict
Joined: 27 Apr 2003
Posts: 96
|
| Posted: Tue Jul 11, 2006 1:27 pm Post subject:
Re: [RFC] mount can figure out fstype automatically
|
|
|
On Tue, Jul 11, 2006 at 12:45:18PM +0100, Robert Watson wrote:
| Quote: |
On Mon, 10 Jul 2006, Christoph Hellwig wrote:
On Mon, Jul 10, 2006 at 01:06:02PM -0600, Scott Long wrote:
So in your opinion and experience, what are the pros and cons of
maintaining a table of magic numbers?
The feature is imensely useful. The implementation won't win any points
for a clean design but works very well in practice. I think it's
definitly better than probing in the kernel because letting a filesystem
driver try to make sense of something that's not it's own format can lead
to all kinds of funnies. Linux does this (iterating all filesystem types
in kernel) for the special case of the root filesystem where mount( is
not available, and it showeds various interesting bugs at least in the fat
driver.
In both FreeBSD and Darwin, I've noticed that the kernel msdosfs code is
excessively permissive as to what it considers a FAT file system. This is
presumably necessary due to the enourmous diversity of FAT file systems
floating around, but it makes it a little too easy to cause msdos to trip
over layouts that violate its layout assumptions. FAT is much more
reliably detected by looking at the partition type it lives in than by
looking at the bytes that appear inside the partition, I believe.
|
Assuming that there is a valid partition type. I don't really know what
this makes, but there's a valid FAT filesystem on it:
% truncate -s 1440k floppy
% sudo mdconfig -a -f floppy
md1
% sudo newfs_msdos -f 1440 /dev/md1
/dev/md1: 2847 sectors in 2847 FAT12 clusters (512 bytes/cluster)
bps=512 spc=1 res=1 nft=2 rde=224 sec=2880 mid=0xf0 spf=9 spt=18 hds=2 hid=0
% sudo mount -t msdos /dev/md1 /mnt
% df -h /mnt
Filesystem Size Used Avail Capacity Mounted on
/dev/md1 1.4M 1.0K 1.4M 0% /mnt
{ceri@shrike}-{~} % fdisk /dev/md1
******* Working on device /dev/md1 *******
parameters extracted from in-core disklabel are:
cylinders=0 heads=255 sectors/track=63 (16065 blks/cyl)
parameters to be used for BIOS calculations are:
cylinders=0 heads=255 sectors/track=63 (16065 blks/cyl)
Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
<UNUSED>
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
<UNUSED>
Ceri
--
That must be wonderful! I don't understand it at all.
-- Moliere |
|
| Back to top |
|
|
John Baldwin
*nix forums Guru Wannabe
Joined: 27 Mar 2002
Posts: 278
|
| Posted: Tue Jul 11, 2006 1:54 pm Post subject:
Re: [RFC] mount can figure out fstype automatically
|
|
|
On Tuesday 11 July 2006 09:27, Ceri Davies wrote:
| Quote: | On Tue, Jul 11, 2006 at 12:45:18PM +0100, Robert Watson wrote:
On Mon, 10 Jul 2006, Christoph Hellwig wrote:
On Mon, Jul 10, 2006 at 01:06:02PM -0600, Scott Long wrote:
So in your opinion and experience, what are the pros and cons of
maintaining a table of magic numbers?
The feature is imensely useful. The implementation won't win any points
for a clean design but works very well in practice. I think it's
definitly better than probing in the kernel because letting a filesystem
driver try to make sense of something that's not it's own format can lead
to all kinds of funnies. Linux does this (iterating all filesystem types
in kernel) for the special case of the root filesystem where mount( is
not available, and it showeds various interesting bugs at least in the
fat
driver.
In both FreeBSD and Darwin, I've noticed that the kernel msdosfs code is
excessively permissive as to what it considers a FAT file system. This is
presumably necessary due to the enourmous diversity of FAT file systems
floating around, but it makes it a little too easy to cause msdos to trip
over layouts that violate its layout assumptions. FAT is much more
reliably detected by looking at the partition type it lives in than by
looking at the bytes that appear inside the partition, I believe.
Assuming that there is a valid partition type. I don't really know what
this makes, but there's a valid FAT filesystem on it:
% truncate -s 1440k floppy
% sudo mdconfig -a -f floppy
md1
% sudo newfs_msdos -f 1440 /dev/md1
/dev/md1: 2847 sectors in 2847 FAT12 clusters (512 bytes/cluster)
bps=512 spc=1 res=1 nft=2 rde=224 sec=2880 mid=0xf0 spf=9 spt=18 hds=2 hid=0
% sudo mount -t msdos /dev/md1 /mnt
% df -h /mnt
Filesystem Size Used Avail Capacity Mounted on
/dev/md1 1.4M 1.0K 1.4M 0% /mnt
{ceri@shrike}-{~} % fdisk /dev/md1
******* Working on device /dev/md1 *******
parameters extracted from in-core disklabel are:
cylinders=0 heads=255 sectors/track=63 (16065 blks/cyl)
parameters to be used for BIOS calculations are:
cylinders=0 heads=255 sectors/track=63 (16065 blks/cyl)
Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
UNUSED
The data for partition 2 is:
UNUSED
The data for partition 3 is:
UNUSED
The data for partition 4 is:
UNUSED
Ceri
|
Dos floppies don't have an MBR (so fdisk on them is meaningless).
--
John Baldwin
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Ceri Davies
*nix forums addict
Joined: 27 Apr 2003
Posts: 96
|
| Posted: Tue Jul 11, 2006 3:04 pm Post subject:
Re: [RFC] mount can figure out fstype automatically
|
|
|
On Tue, Jul 11, 2006 at 09:54:00AM -0400, John Baldwin wrote:
| Quote: | On Tuesday 11 July 2006 09:27, Ceri Davies wrote:
Assuming that there is a valid partition type. I don't really know what
this makes, but there's a valid FAT filesystem on it:
% truncate -s 1440k floppy
% sudo mdconfig -a -f floppy
md1
% sudo newfs_msdos -f 1440 /dev/md1
/dev/md1: 2847 sectors in 2847 FAT12 clusters (512 bytes/cluster)
bps=512 spc=1 res=1 nft=2 rde=224 sec=2880 mid=0xf0 spf=9 spt=18 hds=2 hid=0
% sudo mount -t msdos /dev/md1 /mnt
% df -h /mnt
Filesystem Size Used Avail Capacity Mounted on
/dev/md1 1.4M 1.0K 1.4M 0% /mnt
{ceri@shrike}-{~} % fdisk /dev/md1
******* Working on device /dev/md1 *******
parameters extracted from in-core disklabel are:
cylinders=0 heads=255 sectors/track=63 (16065 blks/cyl)
parameters to be used for BIOS calculations are:
cylinders=0 heads=255 sectors/track=63 (16065 blks/cyl)
Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
UNUSED
The data for partition 2 is:
UNUSED
The data for partition 3 is:
UNUSED
The data for partition 4 is:
UNUSED
Ceri
Dos floppies don't have an MBR (so fdisk on them is meaningless).
|
That agrees with observation Thanks!
Ceri
--
That must be wonderful! I don't understand it at all.
-- Moliere |
|
| Back to top |
|
|
Greg Lewis
*nix forums beginner
Joined: 12 Jul 2002
Posts: 4
|
| Posted: Tue Jul 11, 2006 8:09 pm Post subject:
Re: [RFC] mount can figure out fstype automatically
|
|
|
On Mon, Jul 10, 2006 at 09:22:19PM +0100, Christoph Hellwig wrote:
| Quote: | On Mon, Jul 10, 2006 at 01:06:02PM -0600, Scott Long wrote:
So in your opinion and experience, what are the pros and cons of
maintaining a table of magic numbers?
The feature is imensely useful. The implementation won't win any
points for a clean design but works very well in practice. I think
it's definitly better than probing in the kernel because letting a filesystem
driver try to make sense of something that's not it's own format can
lead to all kinds of funnies. Linux does this (iterating all filesystem
types in kernel) for the special case of the root filesystem where mount(
is not available, and it showeds various interesting bugs at least in the
fat driver.
|
It also (the root filesystem special case) has a tendency to give
misleading error messages which cost me a number of lost hours and
grey hairs in my previous job.
--
Greg Lewis Email : glewis@eyesbeyond.com
Eyes Beyond Web : http://www.eyesbeyond.com
Information Technology FreeBSD : glewis@FreeBSD.org
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Bruce Evans
*nix forums Guru Wannabe
Joined: 22 Mar 2002
Posts: 190
|
| Posted: Thu Jul 13, 2006 11:03 am Post subject:
Re: [RFC] mount can figure out fstype automatically
|
|
|
On Tue, 11 Jul 2006, Robert Watson wrote:
| Quote: | In both FreeBSD and Darwin, I've noticed that the kernel msdosfs code is
excessively permissive as to what it considers a FAT file system. This is
presumably necessary due to the enourmous diversity of FAT file systems
floating around, but it makes it a little too easy to cause msdos to trip
over layouts that violate its layout assumptions. FAT is much more
reliably detected by looking at the partition type it lives in than by
looking at the bytes that appear inside the partition, I believe.
|
Um, most msdosfs file systems are on floppies so they don't even have a
partition.
Msdosfs can be very reliably detected from the bpb provided the bpb isn't
uncleared garbage left from a previous file system, but the checks aren't
very cocomplete and people keep relaxing them. In the old version that
I use, the checks are mainly:
% #ifndef MSDOSFS_NOCHECKSIG
% if (bsp->bs50.bsBootSectSig0 != BOOTSIG0
% || bsp->bs50.bsBootSectSig1 != BOOTSIG1) {
% error = EINVAL;
% goto error_exit;
% }
% #endif
Was relaxed.
% [... a few too many assignments before checking anything]
% /* XXX - We should probably check more values here */
% if (!pmp->pm_BytesPerSec || !SecPerClust
% || !pmp->pm_Heads
% #ifdef PC98
% || !pmp->pm_SecPerTrack || pmp->pm_SecPerTrack > 255) {
% #else
% || !pmp->pm_SecPerTrack || pmp->pm_SecPerTrack > 63) {
% #endif
% error = EINVAL;
% goto error_exit;
% }
Not a very good check.
% if (pmp->pm_Sectors == 0) {
% pmp->pm_HiddenSects = getulong(b50->bpbHiddenSecs);
% pmp->pm_HugeSectors = getulong(b50->bpbHugeSectors);
% } else {
% pmp->pm_HiddenSects = getushort(b33->bpbHiddenSecs);
% pmp->pm_HugeSectors = pmp->pm_Sectors;
% }
Not a consistency check, but how the extension works.
% if (pmp->pm_HugeSectors > 0xffffffff /
% (pmp->pm_BytesPerSec / sizeof(struct direntry)) + 1) {
% /*
% * We cannot deal currently with this size of disk
% * due to fileid limitations (see msdosfs_getattr and
% * msdosfs_readdir)
% */
% error = EINVAL;
% printf("mountmsdosfs(): disk too big, sorry\n");
% goto error_exit;
% }
Consistency check only as a side effect.
%
% if (pmp->pm_RootDirEnts == 0) {
% if (bsp->bs710.bsBootSectSig2 != BOOTSIG2
% || bsp->bs710.bsBootSectSig3 != BOOTSIG3
% || pmp->pm_Sectors
% || pmp->pm_FATsecs
% || getushort(b710->bpbFSVers)) {
% error = EINVAL;
% printf("mountmsdosfs(): bad FAT32 filesystem\n");
% goto error_exit;
% }
Not a very good consistency check.
% pmp->pm_fatmask = FAT32_MASK;
% pmp->pm_fatmult = 4;
% pmp->pm_fatdiv = 1;
% pmp->pm_FATsecs = getulong(b710->bpbBigFATsecs);
% if (getushort(b710->bpbExtFlags) & FATMIRROR)
% pmp->pm_curfat = getushort(b710->bpbExtFlags) & FATNUM;
% else
% pmp->pm_flags |= MSDOSFS_FATMIRROR;
% } else
% pmp->pm_flags |= MSDOSFS_FATMIRROR;
%
% /*
% * Check a few values (could do some more):
% * - logical sector size: power of 2, >= block size
% * - sectors per cluster: power of 2, >= 1
% * - number of sectors: >= 1, <= size of partition
% * - number of FAT sectors: >= 1
% */
% if ( (SecPerClust == 0)
% || (SecPerClust & (SecPerClust - 1))
% || (pmp->pm_BytesPerSec < DEV_BSIZE)
% || (pmp->pm_BytesPerSec & (pmp->pm_BytesPerSec - 1))
% || (pmp->pm_HugeSectors == 0)
% || (pmp->pm_FATsecs == 0)
% ) {
% error = EINVAL;
% goto error_exit;
% }
More not very good consistency checks.
Better checks would determine the location of the FAT and root directory
and check that is there.
% if (pmp->pm_fatmask == 0) {
% if (pmp->pm_maxcluster
% <= ((CLUST_RSRVD - CLUST_FIRST) & FAT12_MASK)) {
% /*
% * This will usually be a floppy disk. This size makes
% * sure that one fat entry will not be split across
% * multiple blocks.
% */
% pmp->pm_fatmask = FAT12_MASK;
% pmp->pm_fatmult = 3;
% pmp->pm_fatdiv = 2;
% } else {
% pmp->pm_fatmask = FAT16_MASK;
% pmp->pm_fatmult = 2;
% pmp->pm_fatdiv = 1;
% }
% }
We do check the FAT, but default to FAT16 if it doesn't lool like FAT12.
% [... a few more]
Bruce
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Oliver Fromme
*nix forums beginner
Joined: 16 May 2006
Posts: 2
|
| Posted: Thu Jul 13, 2006 11:14 am Post subject:
Re: [RFC] mount can figure out fstype automatically
|
|
|
Sorry for re-posting this, but I only posted to the -current
list ... now I'm seeing that the real discussion seems to
take place here on -arch.
Craig Rodrigues <rodrigc@crodrigues.org> wrote:
| Quote: | Scott Long wrote:
So in your opinion and experience, what are the pros and cons of
maintaining a table of magic numbers?
One con: every time you add a new filesystem, you need to update
mount(. Not a big deal, but it is something.
|
How about this idea: Every filesystem registers a piece
of "magic information" somewhere (maybe kenv or sysctl,
or even a file somewhere in /etc or whatever).
Then mount( just has to look at that list, compare in
turn with the device in question, and call the respective
filesystem if found (if the mount fails even though the
magic matched, mount( could print a warning and continue
looking at the remaining filesystems' magics). If a new
filesystem is added, it registers its magic as explained
above. No need to update mount( itself.
For the case where multiple filesystems can share their
structures (like UDF + ISO9660), a priority code could be
assigned, so that the filesystem that's "more useful" (or
more popular) is probed first. Also, filesystems that are
difficult to recognize (like FAT) would get a low priority
code, so they are probed last.
Note that the user can always override the selection by
manually specifying the filesystem with the -t flag of
mount(, so there shouldn't be any regression.
Just my 2 cents.
Best regards
Oliver
--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
"And believe me, as a C++ programmer, I don't hesitate to question
the decisions of language designers. After a decent amount of C++
exposure, Python's flaws seem ridiculously small." -- Ville Vainio
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Sun Nov 23, 2008 11:09 am | All times are GMT
|
|
Free Myspace Comments | Xbox Mod Chip | Mortgages | Credit Cards | ADHD Coach
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
*nix
»
BSD
»
FreeBSD
»
mail-lists
»
Architecture
