ftp server switches file path format

[Maxy2]

I have noticed that when connecting to VMS via FTP, both VMS style and Unix style pathnames can be used, and the choice affects the format of responses that follow. For example:

$ ftp MACHINE.DOMAIN.COM
MACHINE2.DOMAIN.COM MultiNet FTP user process V4.4(119)
Connection opened (Assuming 8-bit connections)
MACHINE.DOMAIN.COM>user
Foreign username: USERNAME
Password:
MACHINE.DOMAIN.COM>cd DEV_SRC:[USERNAME.TEMP]
MACHINE.DOMAIN.COM>ls
DIR1.DIR
FILE$DOLLAR.TXT
FILE1.TXT
FILE2.TXT
MACHINE.DOMAIN.COM>cd /dev_src/username/temp
MACHINE.DOMAIN.COM>ls
dir1/
fileDOLLAR.TXT
file1.txt
file2.txt
MACHINE.DOMAIN.COM>cd DEV_SRC:[USERNAME.TEMP]
MACHINE.DOMAIN.COM>ls
DIR1.DIR
FILE$DOLLAR.TXT
FILE1.TXT
FILE2.TXT
MACHINE.DOMAIN.COM>


The same file will accessable as FILE$DOLLAR.TXT or fileDOLLAR.TXT depending on which mode the FTP server is in.

Where is this behavior documented?

Thanks!

[The Brit]

I cant tell you where it is documented however I have seen the behaviour before.

On VMS, "$" is an acceptable character in a file name.

On some other systems, a "$" is used to delimit uppercase characters.

for example, In openvms, create a file called "$T$OMMY.TXT". A directory listing on VMS shows the file as

$T$OMMY.TXT (since VMS defaults to UPPER case.

however in the unix vernacular it will display as

Tommy.txt.

All characters after the first $ are uppercase, until it reads a second $ or end-of-line.

Dave.

[Steven Schweda]

>
> Where is this behavior documented?

I'd ask the people who supplied the FTP
server.

As a user of the (stone-age/lame) TCPIP FTP
server, I know nothing, but I assume that
the thing is configured to try to accommodate
all the UNIX-expecting software out there, so
that if it sees a UNIX-like "CWD
/some/thing/" command, it responds
accordingly. Perhaps you can disable that
behavior if you don't like it.

Having learned this lesson the hard way, I
modified wget so that it does a "CWD []" at
the end of its normal "CWD where/ever"
sequence, which seemed to be enough to switch
the (TCPware) server where I first observed
this behavior back to VMS mode (when wget is
talking to a VMS FTP server, that is). And
it doesn't seem to bother any of the
VMS-only-looking FTP servers I've seen.

Given the common vendor, I'd guess that the
same trick would work with this MultiNet FTP
server.

[Martin Vorlaender · Accepted solution]

UNIX-Style Listings:
http://www.process.com/tcpip/mndocs52/ADMIN_GUIDE/Ch18.htm#I32

UNIX file name mapping:
http://www.process.com/tcpip/mndocs52/ADMIN_GUIDE/Ch27.htm#I13

cu,
Martin

[Richard Whalen]

Your log shows that you have connected to a system running MultiNet. When a Unix style directory specification is noticed, the MultiNet FTP server will switch from VMS style output to Unix style output. (and vice versa.)
The $ character is a prefix for SRI encoding which is used to maintain case on ODS-2 disks. (Not necessary on ODS-5 disks since they will maintain the proper case of filenames themselves.)

[Peter Zeiszler]

You are also connecting to an older Multinet.
Check out the logical
MULTINET_FTP_UNIX_STYLE_CASE_INSENSITIVE
That helped us on some of our similiar issues.

There is another logical to check too:
MULTINET_FTP_UNIX_STYLE_BY_DEFAULT