Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 15 Nov 1997 00:22:43 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        keith@email.gcn.net.tw
Cc:        Eugeny.Kuzakov@lab321.ru, hackers@FreeBSD.ORG
Subject:   Re: Where to commit patches? [MS Joliet Ext. to CD9660]
Message-ID:  <199711150022.RAA20050@usr06.primenet.com>
In-Reply-To: <19971114235317.02926@email.gcn.net.tw> from "Keith Jang" at Nov 14, 97 11:53:17 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> I've searched the spec of Joliet for weeks, and the only thing I could
> find is the Linux patch. Therefore I must steal from it. :>

If you are an MSDN level II developer,or you have purchased the DDK,
then there is a "Joliet.doc" file in "DDK\DOCS\".  I *was* an MSDN II
developer at my previous empolyer, but now I have purchased the "Visual
Interdev" ``upgrade'' for my Borland C++, and the DDK.

If you have specific questions, I can give you answers, but my license
precludes posting the documents (for example).  I *thought* the Joliet
stuff had actually been disclosed at one time.


> Joliet uses Supplementary Volume Descriptor to store its data. SVD has
> the same format as Primary Volume Descriptor, except for byte position
> 8 & 89-120. The first three bytes starting from the 89th identifies a
> Joliet CD. The first two must be 0x25 & 0x2f. The third represents the
> level, 0x40, 0x43, 0x45 for level 1, 2, 3, respectively.

There is also a volume recognition sequence.  You must go to the last
non-audio session of a multisession CD to perform the recognition.

> The extent of Root Directory Record in SVD is different from that in PVD.
> So that the old code follows PVD->root, and obtains filenames like xxx~1.
> The patch just follows SVD->root to get the right one.

This is the DOS Namespace post collision name.   Windows 95 does not
do late-binding of short names for long file names; they eat the not
inconsiderable overhead up front instead of when a supplementary
reference occurs.  If you had a VFAT/VFAT32 writeable FS that you were
working on, I'd be happy to describe the collision algorithm in detail.
;-).


> The filename in directory record are stored as unicode. Since I have no
> idea of unicode, for now just strip null bytes. Are there any *free*
> unicode resources on the net?

Real Unicode handling requires that you abstract the cn_pnbuf contents;
this is a lot of work on namei(), every FS's VOP_READIR, VOP_ABORTOP,
VOP_RENAME, etc., etc..

To fake Unicode handling, it's pretty simple: treat the character
strings as 16 bit characters (ie: pretend the FreeBSD port of GCC had
gotten wchar_t right).

Then do something like:

FAKE_unicode_to_iso8859_1( int length, unsigned short *from_unicode,
				unsigned char *to_8859_1)
{
	register int	i;

	for( i = length -1 ; i >= 0; i--)
		to_8859_1[ i] = (unsigned char)(from_unicode[ i] & 0x00ff);

	to_8859_1[ i] = 0;
}

This assumes that from_unicode and to_8859_1 point to preallocated
buffers, and the string in from_unicode is length characters long
and there are at least length+1 bytes in to_8859_1.

This works because the values 0x0000 to 0x00ff of the Unicode standard
are ISO 8859-1 characters (8859-1 is a subset of ISO 10646 -- Unicode).

You may want to look at both the Plan9 released code at research.att.com
and the Unicode pages at taligent.com.  Also see the newsgroup
comp.standard.internat.


> That's all I know about Joliet. :) This patch is only sufficient to read
> long filenames. Maybe I'll add an option to make it treat U/L cases the
> same. It does not utilize the three Joliet levels, neither the unicode
> support (I'm not sure whether unicode is supported in FreeBSD.)

The files are case insensitive on lookup, case sensitive on storage
(just like the Mac and OS/2) FS's.  I would not make that work at
this time -- the proper place to handle that is in another VFS layer
stacked on top and grabbing the directory operations.  The big problem
is that pattern matching in user space (like UNIX does) is inherently
case sensitive, even if the VOP_LOOKUP can be made case insensitive.

Plus, any code you write for case folding ought to be portable to
the other FS types that require it.  Assuming you use a filebox or
browser picklist, etc., the files will always be referenced in
the correct case, anyway.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199711150022.RAA20050>