linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Garrett <mjg@redhat.com>
To: linux-hotplug@vger.kernel.org
Subject: Re: LifeDrive filsystem probe fails [mjg59@srcf.ucam.org: Re: LifeDrive and T|X not seen by hal]
Date: Tue, 11 Nov 2008 15:47:04 +0000	[thread overview]
Message-ID: <20081111154704.GA23308@srcf.ucam.org> (raw)
In-Reply-To: <20081111142943.GB18544@zigg.com>

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@srcf.ucam.org

  parent reply	other threads:[~2008-11-11 15:47 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-11 14:29 LifeDrive filsystem probe fails [mjg59@srcf.ucam.org: Matt Behrens
2008-11-11 15:40 ` LifeDrive filsystem probe fails [mjg59@srcf.ucam.org: Re: LifeDrive and T|X not seen by hal] Kay Sievers
2008-11-11 15:47 ` Matthew Garrett [this message]
2008-11-13 12:55 ` LifeDrive filsystem probe fails [mjg59@srcf.ucam.org: Karel Zak
2008-11-13 13:40 ` LifeDrive filsystem probe fails [mjg59@srcf.ucam.org: Re: LifeDrive and T|X not seen by hal] Kay Sievers
2008-11-13 15:07 ` Kay Sievers
2008-11-13 19:01 ` Kay Sievers
2008-11-20 13:17 ` LifeDrive filsystem probe fails [mjg59@srcf.ucam.org: Karel Zak
2008-11-20 14:50 ` LifeDrive filsystem probe fails [mjg59@srcf.ucam.org: Re: LifeDrive and T|X not seen by hal] Kay Sievers
2008-11-21  9:55 ` Kay Sievers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081111154704.GA23308@srcf.ucam.org \
    --to=mjg@redhat.com \
    --cc=linux-hotplug@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).