Is there a simple way to map valid filename chars from one os to another

John E. Malmberg wb8tyw at qsl.net
Sun Sep 17 15:13:56 GMT 2000


"Ron Alexander" <rcalex at home.company>

> Just when I thought everything was under control.
>
> Stratus VOS has a different set of allowed chars for filenames. The
problem
> first showed up when an NT user wanted to create a New Folder. Well VOS
does
> not allow blanks. It also does not allow () that gets added for 2nd and
> subsequent New commands.
>
> I have 'fixed' those issues in filename.c/unix_convert.
>
> Is this the correct approach for simple character translation?

I have a similar problem with OpenVMS for the older filesystem, which must
be accomodated on the system disk.  It is worse for me, as the old
filesystem is case insensitive, and only allows 1 dot in a filename to
delimit the file type.

The first port of Samba to OpenVMS solved this by doing the same thing as an
addon product that provices a LANMAN server to OpenVMS known as Pathworks.

The solution was to replace the offending character with two underscores,
and then the hexadecimal equivalent of the character.

This is basically inserting an escape sequence.

This of course means that some specifications still can not be represented,
and some existing files may become inaccessable as the algorithm is not 100%
reversable.

There is also a convention used with some FTP clients and servers that is
possibly documented somewhere on the WWW possibly even in an RFC, that uses
a $ character followed by a hexadecimal code for an illegal character, or
followed by a alphabetic character to toggle the case setting.

This has the same limitation as above.  It is not OpenVMS specific though.

I ended up putting wrapper routines around all of the C library routines to
translate the UNIX file specifications that SAMBA assumes that all platforms
can handle to ones that the OpenVMS can handle.

>
> A 2nd problem is that VOS is limited to 32 characters in a filename
> (some.file.name)(you can have as many . as you like). The full path is
256.
> At this point I am telling mgmt. we have to live with the 32 char
> restriction. Am I missing an easy way to solve this as well?

The traditional OpenVMS filename is limited to 39 characters for the name
and 39 characters for the type.  (file.type) (Only one ., and never in a
directory) and a total path of 512.  Also directories are normally limited
to 8 levels, but in some cases can be as deep as 15.

You will note that using either of the escape sequences I mentioned above
cuts into the amount of characters left in your filespecification.

If you want the files to be manipulated by both the host operating system
and the client, you will probably have to live with the length restriction.

For OpenVMS, a longer file specification can be hidden as a file attribute,
being stored in an Access Control Entry.  However there is nothing to make
sure that the long filename is unique to a specific file, also if the host
operating system renames the file, it would also cause problems.

For the newer OpenVMS filesystem, I have a different problem.  It can
support file paths of 4095 characters.

This can have some interesting side effects when SAMBA is hardcoded for file
paths of only 1024 characters.

Regards,
John
wb8tyw at qsl.network







More information about the samba-technical mailing list