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