On Tue, Nov 11, 2008 at 04:40:43PM +0100, Kay Sievers wrote: > > Ok. The following things appear to be causing the failure: > > > > 1) The FAT signature in bytes 510 and 511 isn't present. This causes the > > code to bail. > > > > 2) The FAT32 signature in the fsinfo block isn't present. This causes > > the code to bail. > > Hmm, we can not really remove these checks, as there are many volumes > out there which we would detect as FAT, which are not FAT. Most of > these additional checks only got added after a several reports of > mis-detection. Even partition tables may get detected as FAT, if we > remove these checks, without adding new ones. Mm. Some form of "No, really, it's FAT" option keyed off the USB id? > > 3) The loop looking for the root dir appears to jump out past the code > > that sets the filesystem label. This results in it ignoring the UUID > > and filesystem name. > > Is it recognized as FAT, but we jump out of it? Or do we decide that > it is not FAT at all? Is it something that we can fix? That's after I patch the signature checks out. The set_label and set_uuid calls never get made because of the goto found in the loop looking for the root cluster. > > You probably need to get in touch with the udev developers to get this > > fixed - I'm not sure which of these checks could result in false > > positives unless care is taken. Once libvolume_id is fixed hal should > > just work. > > I guess, someone should try to get Palm to come up with a fix for that > thing they call FAT. :) Yeah, good luck with that :) -- Matthew Garrett | mjg59@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
