hal, ntfs, and 10.0-RC3

[Kevin Oberman]

On Sun, Jan 5, 2014 at 11:01 PM, Alberto Villa <avilla at freebsd.org> wrote:

> 2014/1/6 Kevin Oberman <rkoberman at gmail.com>:
> > Since I updated to 10.0-RC3 (from 9), hald no longer works with my ntfs
> > partitions. I can mount them manually with ntfs-3g, but when not mounted,
> > hal does not see them at all.
> >
> > Might this be fall-out of the removal of ntfs (read-only) support? I have
> > not looked through the hald sources to see how it detects these slices. I
> > do find it interesting that mounting one NTFS file system causes all of
> the
> > other ones appear to hald.
>
> I've done some work on HAL in past months, so I have a view on the matter.
>
> HAL uses sysctl for disks detection, so it's up to the system to list
> all the available drives. I'll try to have a look in next days, but my
> wild guess (since I've not been using ntfs-3g for years) is that
> ntfs-3g unloads its module when all mounts are removed, thus making
> the drives undetectable again. Is that correct?
>
> Alberto,

I don't believe this is the case. First, ntfs-3g is entirely user space.
The only kernel code is in fusefs and it is loaded at boot time or compiled
into the kernel. In any case, /dev/ntfs contains all of volumes, so the
system recognizes the slices as NTFS file systems just fine. hald, on the
other hand, does not even see the slices. I suspect that you are looking in
th right direction, though, and that hald uses some different method of
finding partitions than the system and that it fails to work with the
latest fuse code. I would suspect it is somewhere in hal-storage, though I
am far from certain.

I do have an exfat partition and I wonder it that is impacting things. I
does cause somethings odd to happen as it shows up as two slices in the
"gpart list" output but I can't see why hald would suddenly be able to deal
with it when I mount one slice..
-- 
R. Kevin Oberman, Network Engineer, Retired
E-mail: rkoberman at gmail.com