ODS-5 issues: broken utime

[John E. Malmberg]

Ben Armstrong wrote:
> I am working on several issues that prevent me from using the subversion 
> client (either on Windows or Linux) on a VMS Samba ODS-5 fileshare.  I 
> have two patches and one workaround so far*, but require more assistance 
> to solve this one.
> 
> Samba's [.vms]utime.c seems to use the same ACP interface that Perl's 
> vms.c does (apparently both derived from the old file.c utility).  Can 
> we just use CRTL utime for 7.3 and later as proposed for VMS Perl?  
> Also, I didn't see any response in that thread to Craig's suggestion 
> that they enable DECC$EFS_FILE_TIMESTAMPS by default, and don't 
> understand the ramifications if we were to do that, too.

For HP Samba V3 evaluation release, it should be currently using the 
CRTL utime().

All of that code is probably moving into a VFS layer for the production 
release.  At that time, the CRTL may get bypassed to both improve 
performance, and the number of features that will be offered.

A different VFS layer will likely be used to provide ODS-2 support, so 
that the extra processing needed to for it will not impact ODS-5 volume 
handling.

DECC$EFS_FILE_TIMESTAMPS causes different fields in on an ODS-5 volume 
to be exposed by the CRTL.  These fields more closely track what UNIX 
expects.  There are also volume settings that need to be made, and 
increasing the resolution of the timers can impact file system performance.

As some Perl scripts may be expecting traditional OpenVMS behavior, for 
the normal running of Perl, there is no reason to force a setting of 
DECC$EFS_FILE_TIMESTAMPS.

When Perl on OpenVMS learns how to detect that it is running under Bash, 
at that time it will likely also change the DECC$ feature settings to be 
compatible with what a UNIX script would expect.

>   - TC2:
>     - VMS Samba ODS-5 support issue #1: files in directories
>       which begin with a dot (the hidden ".svn" directory on
>       Unix systems) are not visible.
>       - This is not expected semantics: only the directory itself
>         should be considered invisible, not the files within the
>         directory.

I do not understand this issue.  If the directory is invisible, then 
that should be hiding the files.

They still should be accessed explicitly by path name though.

>   - TC3:
>     - Read-only files can't be deleted (not specific to ODS-5).
>     - Here is an excerpt from BG's email to JYC on 29-May-2006
>       about the issue, describing the problem and our workaround.
>       - I have found that Samba removes "D" permission  (unique to VMS)
>         when subversion tries to chmod a file to make it read-only
>         (i.e. removing "W").  This leads to not normal Unix (or Windows
>         for that matter) file semantics: if you make a file read-only,
>         you cannot delete it.  So non-VMS apps operating on the VMS
>         samba share break when they try to remove read-only files.
>       - On non-VMS platforms, whether a file can be deleted or not
>         depends solely upon whether or not the *directory* in which the
>         file exists is deletable.  I propose, therefore, that VMS Samba
>         be modified to leave the "D" bit alone, even when "W"
>         permission is removed from the file.  Does that sound
>         reasonable to you?
>       - My workaround is to put a DEFAULT ACL on the parent directory
>         to grant "D" permission to myself.  It is grubby, but it gets
>         subversion working for me until Samba is fixed.  Would you
>         please look into this, perhaps implementing my suggestion
>         above?

This is an issue where the CRTL unlink() works differently than the UNIX 
unlink().  The UNIX unlink() only pays attention to the write 
permissions on the directory where the file resides, not the permissions 
on the file it self.

Currently the only known work around is to place an ACL on the file to 
always allow delete by the application.

See the PERL vms.c source where it adds a temporary ACL on the file to 
attempt to delete it.

Also the implementation of the DOS readonly attribute can not be 
properly implemented on OpenVMS and possibly on UNIX.

The reason is that the DOS readonly attribute on Microsoft Windows 
trumps all other ACLs that may grant write/delete access, including the 
the privileges of the Administrator account.

Emulating the DOS readonly attribute by ACLs on OpenVMS results in only 
some programs honoring it because of differences.

Implementing the DOS readonly attribute by removing write access from 
system, group, and world is also problematic, because the operation is 
not reversible to grant the proper write access to the file.

A file could start out world writable, and then marked readonly by the 
owner through a SAMBA client.  When the owner wants to make it writable 
again, there is no way to know how to set anything other than the owner 
UIC value.

All in all, implementing the READONLY attribute as an ACL is probably 
the best compromise for functionality, as long as it is realized that 
the ACL may not be honored on the OpenVMS host the same way that a 
Microsoft Windows system.

>   - TC4:
>     - ODS-5 issue #2: extensionless files do not rename correctly
>       when they exist within directories containing dots in them.
>     - Here is an excerpt from BG's email to JYC on 29-May-2006
>       about the issue, describing the problem and our patch for
>       it:
>       - I found I needed this patch:
>         --- vms_support_jyc_1.c 2006-05-29 13:06:04.000000000 -0300
>         +++ vms_support.c       2006-05-29 13:12:54.000000000 -0300
>         @@ -1155,9 +1155,11 @@
>               buf1 = malloc(strlen(buf2)+10);
>               pstrcpy(buf1,buf2);
>               buf2 = vms_encode_filespec(newname,FALSE);
>         -       if (strchr (buf1+1,'.') == 0)
>         +       tmp = strrchr(buf1,'/');
>         +       if (strchr (tmp+1,'.') == 0)
>                       pstrcat (buf1,".");
>         -       if (strchr (buf2+1,'.') == 0)
>         +       tmp = strrchr(buf2,'/');
>         +       if (strchr (tmp+1,'.') == 0)
>                       pstrcat (buf2,".");
>               DEBUG(3,("vms_rename: VMS: %s -> %s\n",buf1, buf2));
>               sts = rename(buf1, buf2);
>         -
>       - Without this patch, if you try to rename a file from, e.g.
>         ".hidden/temp.tmp" -> ".hidden/temp" the rename will appear to
>         succeed (i.e. it will not return an error) but the filename
>         won't change because vms_rename() doesn't append the necessary
>         trailing period, so the ".tmp" extension from the source
>         filename is defaulted for the target filename.
>       - Please apply this patch along with yours for the next release.

Does the DECC$RENAME_NO_INHERIT fix this?

Have you seen any of these issues with the HP Evaluation release?

Regards,
-John
wb8tyw at qsl.net
Personal Opinion Only