ODS-5 issues: broken utime

[Ben Armstrong]

John E. Malmberg wrote:
> For HP Samba V3 evaluation release, it should be currently using the 
> CRTL utime().
>   
That's what I figured.
> 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.
>   
Wouldn't Samba be quite a different matter, then?  I'd expect most 
applications that use VMS Samba would be running on non-VMS systems, so 
non-VMS semantics are perfectly appropriate.  So it sounds like setting 
DECC$EFS_FILE_TIMESTAMPS would be a good thing.
> 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.
>   
If I performed an "ls" on a hidden directory explicitly referenced by 
path name (e.g. "ls .hidden",) no files would be found!  The only way I 
could see files in it was to perform "ls" on each file explicitly (e.g. 
"ls .hidden/foo .hidden/bar").
> 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.
>   
Right.  I understand why it has to work that way.  But what I do 
question is whether Samba should be "aware" of the "D" bit at all.  Just 
as "x" is forced on for all files served from a samba share on a Windows 
host because Windows has no concept of "x", why shouldn't "D" be either 
ignored or forced on?
> 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.
>   
Perl has the advantage of being able to add ACLs as needed.  However, 
when a samba client application creates a read-only file, how is it 
supposed to make the file deletable?
> Also the implementation of the DOS readonly attribute can not be 
> properly implemented on OpenVMS and possibly on UNIX.
>   
That hasn't caused me problems ... yet.  I'm not complaining that DOS 
readonly doesn't map properly.  I just don't understand why chmod 444 
(or even chmod 000) must be interpreted as removing the D bit, given the 
undesirable semantics that result.  After all, if the client doesn't 
even know the D bit is there, why should chmod do anything with it at 
all?  If a samba client really needs to prevent files from being 
deleted, it can be done in the usual way, by taking away write 
permission from the directory on which the files reside.

> 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.
>   
Sounds good if it all works transparently.  But this would have to be 
managed by Samba itself.  It's a bit beyond me to make such extensive 
changes.
> Does the DECC$RENAME_NO_INHERIT fix this?
>   
Even if it does (and it seems like it should) it is a 7.3 feature, 
right?  Since JYC's Samba supports 7.1 and greater, it doesn't seem like 
something we can rely on.

> Have you seen any of these issues with the HP Evaluation release?
>   
In an ideal world, we'd have time to evaluate the HP Evaluation release 
alongside JYC's 2.2.8 release.  However, it doesn't look like it's close 
enough to being ready for production use to grab our interest at this time.

Ben