Conference lassie::ucx

5560.0. "Windows Based FTP Clients Cant LIST File Information" by PRSSOS::DIETZ (Pierre-Etienne DIETZ, Support/France) Tue Jun 03 1997 12:46

  Hello, two questions, an example and a STARS reference:

1) Could someboby help me to find the QAR No of the STARS article 
  appended in annex?

2) When UCX answers to a LIST (FTP) request with a <CRLF> embedded 
  in a record, should we consider that as correct?
  The RFC 959 is not very clear on this issue (LIST command, page 32).
    
3)Example with UCX V4.1 PAT8 + FTP patch 3B1 showing the "extra?" CRLF:
 The basic question appears for me as: "UCX answers to a LIST request 
 with a record that may contain a <CRLF> just after the FILENAME when 
 the FILENAME appears to be longer than 18 characters:

    Example_1 with a 18 char filename
   5A5A5A5A                                     0040               ZZZZ
   2020313B   5A2E5A5A   5A5A5A5A   5A5A5A5A    0050    ZZZZZZZZZZ.Z;1
   20202020   20202020   302F3020   20202020    0060         0/0
   37312037   3939312D   4E554A2D   33202020    0070       3-JUN-1997 17
   442C494D   4548435B   20203434   3A36323A    0080    :26:44  [CHEMI,D
   28202020   20202020   2020205D   5A544549    0090    IETZ]          (
   0A0D292C   4557522C   44455752   2C455752    00A0    RWE,RWED,RWE,)..

    Example_2 with a 19 char filename
   2E5A5A5A   5A5A5A5A   5A5A5A5A   5A5A5A5A    00B0    ZZZZZZZZZZZZZZZ.
   20202020   20202020   2020200A   0D313B5A    00C0    Z;1..
        --> extra? CRLF --> ---^^---^^
   2F302020   20202020   20202020   20202020    00D0                  0/
   554A2D33   20202020   20202020   20202030    00E0    0           3-JU
   2039343A   36323A37   31203739   39312D4E    00F0    N-1997 17:26:49
   20205D5A   54454944   2C494D45   48435B20    0100     [CHEMI,DIETZ]
   4557522C   45575228   20202020   20202020    0110            (RWE,RWE
   6C61746F   540A0D0A   0D292C45   57522C44    0120    D,RWE,)....Total

ANNEX: TIMA/STARS Article, reporting a QAR, but which number? ...
[DEC TCP/IP] Windows[R] Based FTP Clients Cannot List File Information


COPYRIGHT (c) 1988, 1994 by Digital Equipment Corporation.
ALL RIGHTS RESERVED. No distribution except as provided under contract.

Copyright (c) Digital Equipment Corporation 1997. All rights reserved.

PRODUCT:    DIGITAL TCP/IP Services For OpenVMS (UCX), Versions 4.0 ECO 3  
                                                            and 4.1 ECO 2
          
OP/SYS:     DIGITAL OpenVMS VAX, Version 6.2
            DIGITAL OpenVMS Alpha, Version 6.2  
            Windows[R]

COMPONENT:  File Transfer Protocol (FTP)

SOURCE:     Digital Equipment Corporation


SYMPTOM:                        

When using the "show file information" option, windows GUI based FTP 
clients cannot list directory or file information when the server
is UCX.


DIGITAL RESPONSE:

This escalation has been reviewed by Engineering and it has been 
determined to be a design failure. It has been escalated into the 
Engineering Product cycle for consideration into a future release of 
the product. The appendix of the release notes will identify if the
solution has been incorporated. 
\
\
\ ENGINEERING RESPONSE:
\
\ Provided by TCP_IP engineering on 25-FEB-97
\
\ TCP_IP Engineering has reviewed this case and has decided to enter this
\ issue into their QAR data base:
\
\    Your escalation has been reviewed by Engineering and it has been
\    determined to be a design failure.  It has been escalated into the
\    Engineering Product cycle for consideration into a future release of
\    the product. The appendix of the release notice will identify if the
\    solution has been incorporated.
\

[R]Windows is a registered product of Microsoft Corporation.  

\    
\
\ ADDITIONAL INFORMATION:
\
\ These problems were observed on customer's site using Reflection for
\ Windows client and UCX 4.0 ECO2, and UCX 4.1 running on a VAX.
\ It was observed at the CSC using Multinet for Windows client
\ and UCX 4.0 ECO3, and UCX 4.1 ECO2.
\
\ MS Windows based clients cannot see any files listed when using
\ "show file information" option.  Without this option enabled, the client
\ is able to see all the file names correctly.  When using "show file
\ information" option, it is supposed to show the same information
\ gathered by FTP command DIR.  However, using the CLI,
\ FTP command DIR returns all the correct info.
\
\ VMS directories are not recognized as being directories by these
\ windows based clients, therefore clients cannot move down the directory
\ tree by the use of the mouse.  The same directories are correctly
\ recognized by the clients under UCX 4.0 with no patches.
\
\
\ REFERENCES:
\
\ Escalations reported on this problem:
\
\     CHAMP/CSC Service Request (SRQ) #: C970114-4208, C961219-3233
\     Field Service Log #: HPXQ10WSG, MCPMC12WQ      
\ 
\
\ CONTRIBUTORS:
\
\       Technical:
\            Jay So (215415)      
\            Johnny Driggers (70618)
\            Jim Morton (98192)
\            Mark Menkhus (312826)
\
\       Editorial:
\            Cindy Myers (055520)
\
\\ UCX 
\\ PROD=UCX-VMS SPD=25.A4 CAT=COMM GRP=NETAPP OS=OPENVMS-VAX
\\ PROD=UCX-VMS-A SPD=46.46 CAT=COMM GRP=NETAPP OS=OPENVMS-AXP OS=MS-DOS
\\ 215415 070618 098192 312826
\\ HPXQ10WSG SRC970114004208 MCPMC12WQ SRC961219003233        
\\ EDIT_SRQ=C970214-2286
\\ QREVIEW=312827 SOURCE=DIGITAL TYPE=KNOWN_PROBLEM TYPE=ESCALATION

	Hello, 

The STARS article says it's a "design failure". I don't agree, as 
it seems that it was "better" in previous UCX versions:

When the <FileName> was too long, the UCX FTP server used to reply 
to a LIST request as follows, 

With V3.3 ECO7, V4.0 (see note 3900, pb with FTP of RAPIDFILER)

  A <LF> was inserted after the FileName,

and with the latest UCX versions V4.1 PAT8 (pb with Reflection of WRQ)

  the embedded <CRLF> appears in the middle of the record, 
  misleading FTP Clients that cannot make the difference with 
  the End-Of-Record <CRLF>.

=>  Should I report an IPMT (if no fix was planned for UCX V4.2)?

Thanks and regards,
Pierre-Etienne

    I recently fixed a bug in FTP where the lines of output were being
    terminated with "\n" alone.  This violates the RFC, which states that
    the FTP conversation takes place using NVT rules.  A Network Virtual
    Terminal (NVT), like TELNET, changes "\n" to <CR><LF> sequences.
    
    Your question, I believe, is related to the break in the line after the
    file's name when the name is too long.  This occurs for purely cosmetic
    reasons and is apparently a problem to an automated client.
    
    This particular problem should be IPMT'ed.

RE: .2 by UCXVAX::GEMIGNANI 

>  Your question, I believe, is related to the break in the line after the
>  file's name when the name is too long.  This occurs for purely cosmetic
>  reasons and is apparently a problem to an automated client.
Exact, I agree with you.
    
>  This particular problem should be IPMT'ed.
Thanks John, I will do it.

Best regards,
Pierre-Etienne