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