[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-hackers
Subject:    Re: anyone working on upgrading the msdosfs to NetBSD levels?
From:       Robert Nordier <rnordier () iafrica ! com>
Date:       1996-08-01 19:28:07
[Download RAW message or body]

Terry Lambert wrote:
> 
> > The FAT fs primitives are done and tested and I'm currently working
> > on VFAT support.
> 
> Before you get too far on that, I have the algorithm it uses to avoid
> short name name space collisions.  It's not pretty, but it works, and
> I think that was all Microsoft really cared about.

> I'm also not sure about the long name space storage which is in
> ISO-10646/16 (16 bit Unicode), since it is not possible to pass
> Unicode across the lookup interface (this will be a problem for
> any NTFS as well -- Linux is unfortunately way ahead of BSD here).
 
> I can't help with the Unicode stuff given the current state of the BSD
> VFS; my suggestion is to punt, and treat the high byte as zero in all
> cases, converting it to ISO-8859-1 (Latin 1).  This will damage utility
> for anyone outside the Latin 1 scope, but that can't be helped without
> the underlying VFS changes (appologies to non-Latin 1 using countries
> up front).
> 
> If you get to where you need to work on name collision, let me know,
> and I can describe the algorithm in a couple of pages.

I was doing some work on this just recently.  When you have the
time, I'd appreciate your description.  There may be a few points
that my derived algorithm misses.

Following your suggestion of dropping the Unicode high byte, a
primary concern is that this will itself lead to name space
collisions.

I'm a bit vague on the complete range of encodings, but I assume
that LFNs could coexist in a directory where the only difference
is in bits 8-15, which are then masked off.

Alternatively, masking off the high byte may result in a value of
(binary) zero embedded in the LFN, or something equally undesirable.

Won't this entail a further algorithm to produce distinct BSD LFN
representations, or do you forsee another way around this?

--
Robert Nordier

[prev in list] [next in list] [prev in thread] [next in thread]