Operating System - OpenVMS
1748051 Members
5135 Online
108758 Solutions
New Discussion

HP AXPVMS SAMBA V1.2-ECO1 CIFS PS2_11 ALPHA OpenVMS 8.3 ODS2 39 character file name

 
SOLVED
Go to solution
Peter Barkas
Regular Advisor

Re: HP AXPVMS SAMBA V1.2-ECO1 CIFS PS2_11 ALPHA OpenVMS 8.3 ODS2 39 character file name

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.

Peter Barkas
Regular Advisor

Re: HP AXPVMS SAMBA V1.2-ECO1 CIFS PS2_11 ALPHA OpenVMS 8.3 ODS2 39 character file name

My understanding therefore is that CIFS does not fully support ODS-2 compliant filenames on an ODS-2 share because CIFS attempts to provide long filename support on ODS-2.

 

Apparently to support ODS-2 compliant filenames in CIFS requires an ODS-5 share.

Brad McCusker
Respected Contributor

Re: HP AXPVMS SAMBA V1.2-ECO1 CIFS PS2_11 ALPHA OpenVMS 8.3 ODS2 39 character file name

Keep in mind that CIFS is a Windows or LanManager file server.  CIFS (and Advanced Server and PATHWORKS) are attempting to support Windows filenames on a VMS file system.  The result is that one specific file name scenario is not supported (refer to the release note above).

 

I acknowledge that the one specific file name scenario happens to be an ODS2 compliant file name, but, that really is irrelevant in the Windows world which was a significant consideration in the design decisions we made.

 

Brad McCusker

Software Concepts International

www.sciinc.com

Brad McCusker
Software Concepts International
Peter Barkas
Regular Advisor

Re: HP AXPVMS SAMBA V1.2-ECO1 CIFS PS2_11 ALPHA OpenVMS 8.3 ODS2 39 character file name

Response from CIFS engineering.

 

      > Is there a way to prevent the ODS2 VFS module from automatically       

 

      > loading?   If not, is it feasible to implement the ability to  

 

      > negate the loading of the ODS2 module (i.e., vfs objects = no_ods2)?   

 

      > Obviously, that would come with the caveat that any attempt to (use    

 

      > the CIFS server to) create a filename that is not ODS-2 compliant      

 

      > will fail.             

 

       

 

As of now, there is no straight-forward method to facilitate this. But hypothetically, even if we introduce some tweaks to follow this approach, it still may be a risky option.

 

 

 

Internally, the routines in CIFS will treat a file/share as either ODS-2 or ODS-5. Taking the above approach would mean that CIFS has to treat a share as ODS-5 even though it is actually ODS-2. This could lead to unpredictable behaviour. Like you mentioned earlier, the caveat here is any attempt to create a filename that is not ODS-2 compliant will fail; however, we should also keep in mind that such failure need not be a graceful one. It could internally lead to process crash or file corruption.

 

       

 

One possible improvement we might be able to do to address this matter altogether, will be to avoid the encoding/decoding of special characters completely, based on a new flag in SMB config. If this flag is true, the filenames should be used as-is, and the usage of special characters or any filename larger than 39 characters should throw an error (i.e. fail gracefully).   

 

The challenge here is that in the current design, the encoding/decoding mechanism is implemented in several modules; it's not just one global routine that handles this logic. So the code changes required will be a bit more. The testing also will have to be extensive, to make sure backward compatibility is not compromised. Hence we can take this up as an enhancement request for a future release, but I am afraid we won't be able to provide a fix in the current implementation.

Peter Barkas
Regular Advisor
Solution

Re: HP AXPVMS SAMBA V1.2-ECO1 CIFS PS2_11 ALPHA OpenVMS 8.3 ODS2 39 character file name

To me it is a bug, to others, it seems, including CIFS engineering, it is a side effect of a feature.

Brad McCusker
Respected Contributor

Re: HP AXPVMS SAMBA V1.2-ECO1 CIFS PS2_11 ALPHA OpenVMS 8.3 ODS2 39 character file name

Peter -

 

Your summary view of the situation is accurate.  If we were talking about PW/AS, however, there would be no ambiguity - it's a know limitation in the product.  Fortunately I no longer need to defend that position :) 

 

(It probably won't be any consolation, but I can assure you that there was indeed significant effort put into removing this limitation including a "fix" that made it at least as far as some builds.  It wasn't done on a whim)

 

Brad McCusker

Software Concepts International

www.sciinc.com

 

Brad McCusker
Software Concepts International