Stratus VOS port status and issue.

[John E. Malmberg]

Ron Alexander <rcalex at home.company> wrote:

> The Stratus VOS port is progressing at a good rate. Last night I attached
to
> the VOS machine and selected a bunch of files.
Good.
>
> Now for a problem that I hope the experts will be quick to solve.
>
> The path names on VOS start with a % sign. Here is what I see in my log
> file.
>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> [2000/05/12 09:36:07, 3] loadparm.c:(1525)
>   adding home directory Ron_Alexander at
> %swsle#m12_user>Stratus>Ron_Alexander
>
> [2000/05/12 09:36:16, 0] service.c:(486)
>   Can't change directory to _swsle#m12_user>Stratus>Ron_Alexander (No such
> file
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>
> As you can see the % has been replaced by a _ causing a file not found
> error.
>
> We are well aware of the larger problem of trying to get our file system
to
> be compatible with a Unix style system, but this is a problem we did not
> expect.
> Other than some possibly major code modifications for VOS (a practice I
have
> avoided so far) is there a way to resolve this in Samba.

For OpenVMS, this problem also exists.  A local OpenVMS "ODS-2" file
specification is:

DISK:[dir1.dir2.dir3.dir4.dir5.dir6.dir7.][dir8.dir9.dir10.dir11.dir12.dir13
.dir14.dir15]filename.extension;version

Where only "A-Z,0-9,_,-" are allowed as file characters, and the first
character can not be "-".  Basically all of the segments are also limited to
39 characters and the total length can not exceed 256 characters.

OpenVMS now has a new file system that removes many of these restrictions
known as ODS-5, but it is only available with OpenVMS-Alpha 7.2 and later.

Digital/Compaq solved the problem of having "illegal" characters in a file
name in their Pathworks Server product by replacing the "bad" character with
"__XX", where the XX is the hexadecimal of the ASCII code for that
character.

The SAMBA-VMS ports have continued with that convention.

Using the CHARCNV.C module to do the conversion was my first choice for
doing the conversion.  It worked very well for the SMBD program, and allowed
me to hit most of the functions that referenced the name.

However, when I ran the SMBCLIENT program, I discovered that the conversion
routines made all of the remote client files look like they were LOCAL VMS
filenames instead of how they should have been represented.

Eckart Meyer's port of SAMBA to VMS used a wrapper on the C library routines
that referenced filenames to convert from UNIX format that SAMBA expects
them to have.

I ended up doing the same, however I am using a different conversion routine
as the original one did not implement features that I was use to having.


James Sutherland <jas88#cam.ac.uk> wrote:
:
:  Have you considered patching dos_to_unix() to convert VOS file paths to
: Unix ones? (i.e. replace %, # and > with /, and vice versa? This looks
: like the "cleanest" place to do it, AFAICS.

dos_to_unix() and unix_to_dos() will probably not work.  Experience on the
OpenVMS port has shown that the name must be translated host format at the C
library call that uses it.  Any filespec returned from a library call must
be translated to the UNIX format.

While this currently can result in a lot of translations back and forth, all
the other places seem to have some condition where it does not work.

-John
wb8ytw at qsl.network