RFC 3659, "Extensions to FTP", March 2007

Errata ID: 1500
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maik Reiß (Reiss)
Date Reported: 2008-09-02
Held for Document Update by: Barry Leiba

Section 7.7.4 says:

7.7.4.  A More Complex Example
 ...
C> MLSD test
S> 150 BINARY connection open for MLSD test
D> Type=cdir;Perm=el;Unique=keVO1+ZF4; test
D> Type=pdir;Perm=e;Unique=keVO1+d?3; ..
D> Type=OS.unix=slink:/foobar;Perm=;Unique=keVO1+4G4; foobar

It should say:

7.7.4.  A More Complex Example
 ...
C> MLSD test
S> 150 BINARY connection open for MLSD test
D> Type=cdir;Perm=el;Unique=keVO1+ZF4; test
D> Type=pdir;Perm=e;Unique=keVO1+d?3; ..
D> Type=OS.unix=symlink;Perm=;Unique=keVO1+4G4; foobar
     ... more lines ...
D> Type=dir;Perm=;Unique=keVO1+4G4; /foobar; does originally point to here

Notes:

The sample sequence in chapter 7.7.4 uses an example which is completely wrong, because it violates the basic BNF rules of its own document.

Please, see the definition, which is violated:

7.2. Format of MLSx Response
The format of a response to an MLSx command is as follows:
...
entry = [ facts ] SP pathname
facts = 1*( fact ";" )
fact = factname "=" value
...

Remember, a fact may not contain ";" or SPC (" ")!
Now take a look into the bad example:


7.7.4. A More Complex Example
...
C> MLSD test
S> 150 BINARY connection open for MLSD test
D> Type=cdir;Perm=el;Unique=keVO1+ZF4; test
D> Type=pdir;Perm=e;Unique=keVO1+d?3; ..
D> Type=OS.unix=slink:/foobar;Perm=;Unique=keVO1+4G4; foobar


the last line uses the fact "Type=OS.unix=slink:/foobar;". While this line in special not violates the rules at the moment, it implies that "Type=OS.unix=slink:" starts printing the original link target of any given symbolic link. Not wrong till here, but in case a link points to an original directory which name contains a ";" or, most worse, a "; " sequence, it will
lead any client side PI into misinterpretation of the line.

Even more worse, some actual public servers already use this bad syntax. Some can be found at least in the Swiss. It looks like they are running proftpd under Linux operating system, but this is unconfirmed for now.


Solution:

The chapter 7 of the same document allows another approach to tell the client about the original destination of a symlink. This solution uses two lines of answer, see my example:

C> MLSD test
S> 150 BINARY connection open for MLSD test
D> Type=cdir;Perm=el;Unique=keVO1+ZF4; test
D> Type=pdir;Perm=e;Unique=keVO1+d?3; ..
D> Type=OS.unix=symlink;Perm=;Unique=keVO1+4G4; foobar points somewhere else
... more lines ...
D> Type=dir;Perm=;Unique=keVO1+4G4; /foobar; does originally point to here

because of the "Unique" fact, a client PI can now collect all lines with the fact "Type=OS.unix=symlink" and file it under an associative array (map, hastable) with "keVO1+4G4" as the access key. Once the client side parser again gets "Unique=keVO1+4G4", it now can record "/foobar; does point to here" as the original point where foobar points to.

This is exactly, what chapter 7.5.1.5 defines about the "Unique" fact. Please read:
Note: Where the underlying system supports a file type that is
essentially an indirect pointer to another file, the NVFS
representation of that type should normally be to represent the file
that the reference indicates. That is, the underlying basic file
will appear more than once in the NVFS, each time with the "unique"
fact (see immediately following section) containing the same value,
indicating that the same file is represented by all such names.


Useful to say, setting the slink into double quotes like suggested by some developers:

D> Type=OS.unix="slink:/foobar";Perm=;Unique=keVO1+4G4; foobar

would violate the same documents BNF rules (see RCHAR), as well it would require escaping of any DQUOTE in the link pathname itself. This, again, would violate RFC959 which not defines escaping of characters.


Finally, FTP does not support 2 pathnames at the same line at all. This convention sould never been broken.

Report New Errata