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
[EMAIL PROTECTED]
Personal Opinion Only
PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING:
http://www.catb.org/~esr/faqs/smart-questions.html
