ODS-5 issues: broken utime
John E. Malmberg
wb8tyw at qsl.net
Thu Jun 1 20:58:02 GMT 2006
Ben Armstrong wrote:
> John E. Malmberg wrote:
> 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.
You are probably right. It can be added in a lib$initialize module, or
as a wrapper to a routine that calls the original main routine.
>> 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").
That is what I would expect. I suspect that this is an issue with the
SAMBA V2 port. I have seen reports of problems with directories that
contain periods in their name.
>> 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?
Traditionally on OpenVMS, if you use the C runtime to set UIC based file
permission of writable, it also set the delete bit.
So that for files created by the SMBD process, there should be no
problem with write access being granted without delete access.
For files that the protection is set on the OpenVMS system, I personally
do not think that the SAMBA server should automatically assume that
having write access implies delete access.
>> 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?
The client should just have to make it writable if it has permissions to
change the attributes on the file.
>> 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.
I am not aware of that occurring. Again, as I understand things, the D
bit should follow the W bit for file protections made through the C runtime.
>> 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
>> 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.
Unfortunately I do not have a chart of the minimum releases for DECC
features settings existing. It looks like additional code would be
needed for that.
>> 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.
I understand. The OpenVMS CIFS team is working on making improvements
to it now so that should not be the case in the future.
wb8tyw at qsl.net
Personal Opinion Only
More information about the samba-vms