Iomega USB external hard drive

[Javier Ros Ganuza]

I'm not an expert and obviously the following idea can be perfectly
stupid but there goes:

In my case the variable

volume.partition.msdos_part_table_type

takes the value

int="0x83"

this clearly resembles there is a linux partition there (in a correct
drive configuration).

In that case the longer check you have mentioned could be performed,
and the volume.fstype label settled correctly (don't know where this is
set). At this case the mentioned delay can be acceptable, I think.

¿Can this work?

A similar procedure could be implemented for filesystems whose typical
formaters do no clear the mentiones 0x400 bytes.


Javier




On Wed, 2005-04-06 at 19:46 +0200, Kay Sievers wrote:
> On Wed, Apr 06, 2005 at 11:10:52AM -0400, David Zeuthen wrote:
> > Hi,
> > 
> > I think that the problem here is that the software that you used for
> > formatting the partitions has a bug - specifically, the problem is that
> > the file system signatures for ext3 start at offset 0x400 while it
> > starts at offset 0 for FAT. Thus, on a ext3 filesystem you may have what
> > looks as a valid vfat signature and the bug is that the software you
> > used for formatting the ext3 file system should have cleared the first
> > 0x400 bytes but it didn't. You may do that manually yourself though.
> > 
> > I'm not sure how to best approach this problem, maybe we should probe
> > for ext3 (and other fs'es where the super block isn't at offset 0)
> > before vfat? I just remember a whole lot of problems when we did that
> > and I think we changed it for a reason. What do you think Kay?
> 
> We changed it cause it slowed down probing on very slow devices. I still
> see it as a serious bug in the formatting software. We have the same
> problem with mkswap by the way, but the main(enter)tainer says it is
> a feature to be able to recover data after a wrong use of mkswap and
> denied to change it. If you run mkswap on a fat volume, you can even
> mount the now corrupted disk.
> We should file bugs against all broken mkfs stuff. I don't see
> how we can solve that with HAL, if we change the order now, other users
> will have the same problem the other way around...
> Any better idea?
> 
> Kay
> 

_______________________________________________
hal mailing list
hal at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal