Response from CIFS engineering:
The behaviour observed in the case of 39 character filenames in ODS-2, is a limitation by design. While saving files in a share hosted on ODS-2 disks, CIFS uses certain conventions to encode the filename, in order to overcome the restrictions imposed by ODS-2 syntax to some extent. The issue that customer is facing (disappearing dot) is because of this mechanism.
For example, consider the below file created by Windows in a network share, hosted by CIFS on ODS-2. This filename has 40 characters, and doesn't have any extension (filename extension is optional in Windows):
>
> C:\>DIR O:\DIR1
> Volume in drive O is ONC_ODS2_STREAM > Volume Serial Number is 50FD-0BAF > > Directory of O:\DIR1 >
> 01/31/2014 12:38 PM <DIR> .
> 08/27/2013 05:05 PM <DIR> ..
> 01/31/2014 01:26 PM 132 10-CHAR---10-CHAR---10-CHAR---10-CHAR---
> 1 File(s) 132 bytes
> 2 Dir(s) 36,213,514,240 bytes free
>
> C:\>
When CIFS saves the same file in ODS-2 disk, it'll append a dot after 39 characters. Basically, this is a "pseudo dot" i.e. it's not actually part of the original file name in Windows. Here CIFS is trying to support filenames more than 39 character length (which is the maximum allowed in ODS-2) by marking the 40th character onwards as part of extension instead of filename.
Hence the file created by Windows will appear in VMS as below:
>
> ONC59 $ DIR
>
> Directory $3$DKD0:[CIFS_ODS2.ONC_ODS2_STREAM.DIR1]
>
> 10-CHAR---10-CHAR---10-CHAR---10-CHAR--.-;1
>
> Total of 1 file.
> ONC59 $
Now, consider a scenario where Windows creates a file that actually has dot after 39 characters:
>
> C:\>DIR O:\DIR1
> Volume in drive O is ONC_ODS2_STREAM > Volume Serial Number is 50FD-0BAF > > Directory of O:\DIR1 >
> 01/31/2014 12:38 PM <DIR> .
> 08/27/2013 05:05 PM <DIR> ..
> 01/31/2014 01:26 PM 132 10-CHAR---10-CHAR---10-CHAR---10-CHAR---
> 01/31/2014 01:51 PM 144 10-CHAR---10-CHAR---10-CHAR---9-CHAR---.TXT
> 2 File(s) 276 bytes
> 2 Dir(s) 36,213,473,280 bytes free
>
> C:\>
Here also, CIFS will have to use pseudo dot after 39 characters; otherwise, it would be impossible to differentiate a pseudo dot and a real dot. Now, after the pseudo dot, CIFS cannot put the extension ".TXT" as-is, because ODS-2 doesn't allow more than one dot in filename. Hence, CIFS encodes the dot as "__2E" (the ASCII hexadecimal value of dot; same mechanism is used for other special characters restricted by ODS-2, but supported by Windows). So the filename will show up as below in VMS:
>
> ONC59 $ DIR /COL=1
>
> Directory $3$DKD0:[CIFS_ODS2.ONC_ODS2_STREAM.DIR1]
>
> 10-CHAR---10-CHAR---10-CHAR---10-CHAR--.-;1
> 10-CHAR---10-CHAR---10-CHAR---9-CHAR---.__2ETXT;1
>
> Total of 2 files.
> ONC59 $
The bottom line is that CIFS uses it's own file naming conventions while saving files on ODS-2 disks, in order to alleviate the gap between Windows file system and the limited syntax of ODS-2. This works smoothly for files are accessed only from Windows. However, when same files are accessed by applications running in Windows and VMS alike, in some cases, the filename might be interpreted differently by CIFS and other applications running in OpenVMS; which is what happens in the scenario of 39 character filename. A similar example is if an application creates file named "A__2CB.TXT;1" in the
ODS-2 directory, CIFS will interpret it as "A,B.TXT" because comma is encoded as "__2C" while creating files from Windows.
We won't be able to fix this in code without dropping support for filenames above 39 characters; and withdrawing support would be unacceptable for most users. As a work-around, the customer can use ".__2E" while creating filenames with 39 characters. But if that is not feasible, the only alternative is to use ODS-5 disks, which doesn't impose any of these naming restrictions.
