Subject: Ftp-WG: Quick MLST/MLSD questions.

From: Stephen Tihor <[email-masked]>
Date: Wed, 1 Sep 1999 00:40:10 -0400

While I am inclinded to agree this is a quality of implementation issue I 
should suggest that the DOS, WINDOWS, or NT suggested facts set should 
include standard replies for this case. eg:

Shortcut's are files and thus report all the normal information for the
shortcut as a file iff this implementation of FTP treats them as files
that can be uploaded and downloaded.    Otherwise they report the information
about the file they are a shortcut for. 

in either case the also report the facts 

NT.shortcutto=THe unique path to the target file which can be absolute or relative to this location if an absolute path is not possible
NT.shortcuttosize=Size of the target file. 

etc.

---

From: Robert Elz <[email-masked]>
Date: Wed, 1 Sep 1999 01:18:55 -0400

Date:        Tue, 31 Aug 1999 14:15:49 -0400
    From:        Alun Jones <[email-masked]>
    Message-ID:  <[email-masked]>

  | 1a. If a directory is hidden, and has no contents (and its parent is also a
  | hidden directory), what should appear in the MLSD output of that directory?
  |  Should it be an empty data stream, or should one see a 5xx error?

What does the native OS do when a local user lists the directory?   If hidden
really means hidden, then I'd expect an error ("you don't know that exists").
On the other hand, if hidden is closer to "if you know about this OK, I
just won't tell you by default" (similar to the '.' comvention on unix)
then I'd expect to see the files listed.    If a directory truly has nothing
in it that wants to be listed, then an empty response would be OK, though if
the user has named the directory on the MLSD request (or a previous CWD to
make the directory be the current one, so it can be listed without naming it),
then I see no problem with at least returning a type=cdir in the response
using the name you know that the user already knows.

  | 1b. Are there any other situations where a client might validly see an
  | empty data stream as a result of MLSD?  Should the draft note that an empty
  | data stream is a valid result?

I guess.   It already does if you believe the grammar...

	data-response   =       *( entry CRLF )

but saying the same again in prose can't hurt.

  | 1c. Should MLST show details for a named file if it is hidden?  [Command
  | prompt doesn't list even a named file, if it is a hidden file, without the
  | '/A' or '/AH' parameters]

Whatever you like.   Add a MLST option to allow listing it or not.
If the user has requested the DOS.hidden fact, then show hidden files,
and include that fact with a value to indicate whether the file is
hidden or not.   If they haven't asked for that fact then give an
error (or don't include the file in a MLSD listing).

  | 2. Win32 has shortcuts; Unix has links.  When MLST or MLSD are reporting
  | details of a shortcut file, what facts should be displayed pertaining to
  | the target of the shortcut, and what facts should be displayed pertaining
  | to the shortcut itself?

My intent there was to always give information on the thing that will be
fetched if the user says "RETR filename".   If for a shortcut, that would
be the file the shortcut references, then as far as the NVFS is concerned
the shortcut is the file.   The same applies to both real, and symbolic,
links under unix (where RETR certainly gives you the content of the file,
not the symbolic link).   This is the same answer as Stephen Tihor gave
I believe.

What is important here is that FTP (by default) needs to allow clients and
servers running on totally different OSs to communicate sensibly.  Telling
a unix system that "I see a shortcut" is essentially useless.   Just as
telling a windows system "I see a hard link" is.   That's what the unique
fact was supposed to convey - these two files are the same thing on this
system (they represent the same data bits, not just two copies of the same
bit values).   Then the client can represent that as a shortcut, a link,
or a symbolic link, at its discretion - the same effect will be achieved.

Then, once you get to situations where the client and server shake the
secret handshake, by which each identifies the other as a member of its
own secret lodge, they can agree that things should e different between
them so as to make life easier for known compatible systems - you're a
DOS, I'm a DOS, we're all dossers, so I can say "type=OS.DOS=shortcut"
to you and you will know what I mean.   That kind of stuff is for private
agreement (but IANA registration).

kre

---

From: Alun Jones <[email-masked]>
Date: Tue, 7 Sep 1999 21:19:36 -0400

At 02:54 PM 8/31/99 -0400, you wrote:
>My $0.02 ...
>
>On Tue, Aug 31, 1999 at 02:15:49PM -0400, Alun Jones wrote:
>> 2. Win32 has shortcuts; Unix has links.  When MLST or MLSD are reporting
>> details of a shortcut file, what facts should be displayed pertaining to
>> the target of the shortcut, and what facts should be displayed pertaining
>> to the shortcut itself?
>
>The least-common denominator, please.  Other facts MAY be there, but the
>only ones which SHOULD be there are those one would reasonably expect to
>exist in all implementations ofthis type of feature.  Namely:
> - Hi! I'm item number X
> - I'm an "alternate name"
> - I point to item Y
> - I think item Y's name is this
>If you want to know more, ask item Y.

You didn't answer my question, or at least, not in a manner that I even
remotely understood.

The shortcut is a file - it's not an inode-based thing, like a Unix link.
Hence, the shortcut itself has a size, and a modification time, as well as
a name.  For instance, I have a shortcut file on my desktop folder labeled
"Eudora", which is a link to "D:\Program Files\Winsock
Programs\eudora\Eudora.exe" - when MLSD occurs with my desktop folder as
the target, should the name listed be
"D:\Winnt\Profiles\Alun\Desktop\Eudora" or "D:\Program Files\Winsock
Programs\eudora\Eudora.exe"?

This shortcut occupies 587 bytes, and has a modification time of Sunday,
March 15, 1998 5:38:12 PM - its target occupies 1,139,712 bytes, and was
last modified Tuesday, October 21, 1997 1:02:10 PM.  Now, in the MLSD of my
desktop directory, what should be listed in the size fact, and what in the
modify fact?

Alun.
~~~~

---

From: Stephen Tihor <[email-masked]>
Date: Wed, 8 Sep 1999 09:57:33 -0400

There are two moderately different virtual file system models possible here. 

the shortcut is treated like a link.   RETR it and you upload the thing it
points to.  STOR it and you replace the thing it points to. (?)  In that case
MLS* it and you should get the stats for the thing it points to with the
shortcut's attributes as OS specific facts at best.  The same unique fact as
the thing it points to. 

The shortcut is a special file.    RETR it and you get its pointer value, 
STOR it and you make a new shortcut (?).  MLS* it and you get the stats for the
shortcut as file plus perhaps an OS specific pointer to the underlying file. 
A different unique fact.