Regular Advisor 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.