<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Yes, Unix' <font size="+1"><tt>ls</tt></font> does have its
unique ideas... I was forced to implement some of them as certain
brain-damaged FTP clients think that when are you speaking to an
FTP server which claims TVS compliance (I.E., Tops-20 Extended
Mode FTP), that you must be Unix and be able to shell out. They
literally issue the <font size="+1"><tt>ls</tt></font> directly
over the control channel instead of the RFC959 compliant <font
size="+1"><tt>STAT</tt></font> or <font size="+1"><tt>LIST</tt></font>
verbs! No where is this documented in any RFC; you've got to
snoop the line. Grrr...</p>
<p>But we may be talking apples and oranges; there is a difference
between VMS requesting a listing of a locally attached file system
(or even in a cluster) and using DAP. My guess is that DAP only
allows one response per command; that quite different from the
previous case where you are free to whine about each file.</p>
<p>Tops-20 directories are quite different animals than either Unix
or Windows, both in implementation and semantics.<br>
</p>
<div class="moz-cite-prefix">
<p>I will follow up with you off list concerning tests with RSTS,
perhaps over the weekend when I'm finished figuring out what to
do.</p>
</div>
<div class="moz-cite-prefix">
<p>I have some very fond memories of the RSTS system at Columbia.
It was our first experiment in time sharing technology before we
acquired 6 DECSYSTEM-20's. The RSTS system was an 11/50 running
RSTS/E and it was a fabulous base for introductory programming.
A number of us were sad to see it go as opposed to being
replaced with an 11/70, but we had to put a 20 there.<br>
</p>
</div>
<blockquote type="cite"
cite="mid:A78F0452-866F-497C-B46D-FD632FA66DDB@comcast.net">
<hr width="100%" size="2">
<pre class="moz-quote-pre" wrap="">On 12/20/19 1:33 PM, Paul Koning wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">On Dec 20, 2019, at 1:12 PM, Thomas DeBellis <a class="moz-txt-link-rfc2396E" href="mailto:tommytimesharing@gmail.com"><tommytimesharing@gmail.com></a> wrote:
I have been working with a kind volunteer who is using OpenVMS Alpha. It's been quite productive.
While I haven't run into any security exposures, yet, the experience has enabled me to find a few things to tweak up. For example, the VMS logging and reporting was clearly superior to what was being put in the FAL log (which wasn't even timestamped and didn't have the requested file name).
We ran into some interesting behavior. When ANONYMOUS access is restricted to the stand-in user and its subdirectories, wildcard listing requests that are outside of that lexical scope do not report any errors but rather return zero files (none). That was puzzling because the part of the code that did the access check was clearly doing the reject with appropriate return values.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Not clear if that's an error. In RSTS at least, if you asked for a list of files, you'd be given the subset of files that you have read access to. Files for which you have no permission would appear nonexistent. This is rather different from the behavior in Unix, which shows you all files in a brief listing, and a pile of error messages in a long listing.
Whether VMS follows the same model I'm not sure. It's a bit more work in systems like RSX or VMS, which like Unix separate directory names from the underlying file object where the permissions live.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Further analysis showed that in the main loop for stepping wildcards, a reject causes the file in question to be skipped; nothing is actually done with the return values. I believe this may be intended behavior for two reasons. The first is that if the wildcard includes files to which the ANONYMOUS user does legitimately have access, it's friendlier to report those as opposed to stopping everything.
The other reason I believe has to do with DAP itself; I don't think you can't return more than one return value per ACCESS request, even with a wildcarded file specification. So perhaps this isn't a bug so much as an unintended consequence? Does anybody know what the behavior should be?
At any rate, I don't believe the current behavior is 'informative'. What I'm thinking of doing is saving the last error code and returning that if the count of files returned in list is zero. Otherwise, the user had something to look at.
Do I have any volunteers who operate something besides VMS? I'd be interested in RSX(+), IAS, RSTS and OS-8. They never did DECnet on RT-11, did they?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
I can offer help with RSTS. Yes, there is DECnet/RT11, but I don't know if we have any on HECnet or if the code has even been preserved.
paul
</pre>
</blockquote>
</body>
</html>