[Fwd: Re: RE : dots in directory names of shares on ODS-5 disks]

[BG - Ben Armstrong]

David and I discussed privately why ODS-2 has trouble with dots in
filenames.  With his permission, I am forwarding the following to this
list, as I still need some clarification about why it is that
directories with dots in them only partially work on ODS-2.  It seems to
me a mkdir of a directory with a dot in it should either fail completely
or succeed, rather than create the directory, but subsequently fail to
locate it.

Also, I still don't understand why a workaround is not possible.  If
there is no workaround, several otherwise useful Unix applications
(Subversion is the one I'm interested in today, but there are others)
cannot operate on Samba ODS-2 shares because they heavily rely on files
kept in directories with dots in them.

Thanks,
Ben

-------- Forwarded Message --------
David,

On Wed, 2005-07-13 at 19:51 -0500, David J Dachtera wrote: 
> >Why not on ODS-2 disks?  The current behaviour is badly broken:
> 
> The reason is because in ODS-2, there is only one "dot" in a filespec, and
> that "dot" is the delimiter between the file's filename and its filetype
> extension, typically expressed like so in examples:
> 
> device:<directory>filename.extension;version

I'm perfectly aware of that.  With the current implementation of Samba,
when you mkdir a directory with a dot in it, the dot gets encoded as
__2E by Samba, and Samba actually creates the directory.  But Samba
subsequently fails to locate the newly created directory and throws an
error.  However, if you create a plain file with a dot in it, the file
can subsequently be located.  Why doesn't this work for directories?

> In ODS-2, a directory name always looks like this:
> 
> name.DIR;1
> 
> ...where "name" can be any string of characters including A-Z, 0-9, "$",
> "_" or "-" (dash is accepted, but not recommended). The extension is always
> ".DIR" and the version number must be "1". Thus, there is no "transparent"
> way to mask a non-conforming directory filespec and convert it to a
> conforming one. Specifically, the direcory name cannot be null (".DIR;" is
> not a valid directory file name).

This part, I don't understand, even after reading (OK, skimming, as this
is all very familiar to me after twenty years of professional software
development on VMS) the pages from your site that you cited.  If Samba
is told to look up a directory (or file, as we don't know which it is
when we look it up) called ".name" on ODS-2, couldn't it first look for
"__2ENAME." and if that is not found, then look for "__2ENAME.DIR;1"?
What's the big deal?  And if we ask Samba to look for ".svn/config" then
the directory portion is perfectly unambiguous; Samba knows to look for
"config" in "[.__2ESVN]" because of the slash in the filepath.

Ben