Subject: RE: ftp filename case conversions

From: [email-masked]
Date: Tue, 2 May 95 08:50:24 PDT

wu.ftpd, being a Unix server with case sensitive file names, 
has no reason to monkey with the case of incoming file names. 
For my part I would not want wu.ftpd to touch a file name; that 
will only open up confusion with ftp clients that want the file 
name to stay like it was originally sent.

The problem is Microsoft.  I just ran FTP32 from a Windows 3.11 
system here inhouse, and it did just what you described - it 
capitalized the file name for me.  They must think they can 
take the liberty of doing what they want with the file name, 
not understanding that the vast majority of servers around are 
case sensitive and that users might care what case the file 
ends up.  I have no idea if there are configuration options on 
TCP32 to change this; I wouldn't much expect it.

Don't know what options are available to run from scripts - I 
primarily use WS_FTP, which is a windows oriented ftp client.  
There may be good freeware command line clients available, I 
just don't know any.  Hope you find something...

Michael

On Mon, 01 May 1995 17:03:15 -0300  Manfred Humphries wrote:
>I am trying to use Microsoft's MSFTP client to upload files 
under script   
>control - works like a charm, except that either MSFTP or 
WU-FTPD changes 
>the case of the filename from lower case on the client to 
UPPERCASE on   
>the server.  This is causing me some real headaches.  Do you 
have any   
>ideas about configuring FTPD to prevent this?
>
>

---

From: Cary Talbot <[email-masked]>
Date: Tue, 2 May 1995 11:59:47 -0500 (CDT)

Hello:

I just subscribed to this list and therefore apologize if this topic has
been recently discussed...

I recently installed the Wu-ftpd server on my machine and it seems to be
working just fine except for one thing... 
The decompression/compression of files by omitting/adding the .Z or .gz 
extensions does not work.  To the best of my understanding, I have 
specified the proper options in the config files and placed copies of 
the executables in the ~ftp/bin area.  However, whenever I try to use
this feature, ftpd responds with the 
"150 Opening BINARY mode data connection for /bin/gunzip" or
"150 Opening BINARY mode data connection for /bin/gzip" 
but then the transfer abruptly concludes, leaving a the correct file name 
but the file is of zero length.  The "xferlog" shows (correctly) that the
file was transfered but that the file length was 0 bytes.  

Does anyone have any ideas?  Here is the relevant portion of my 
ftpaccess file:
...
compress        yes             local remote
tar             yes             local remote
...

and from my ftpconversions file:

 :.Z:  :  :/bin/compress -d -c %s:T_REG|T_ASCII:O_UNCOMPRESS:UNCOMPRESS
 :   : :.Z:/bin/compress -c %s:T_REG:O_COMPRESS:COMPRESS
 :.gz: :  :/bin/gunzip -c %s:T_REG|T_ASCII:O_UNCOMPRESS:GUNZIP
 :   : :.gz:/bin/gzip -9 -c %s:T_REG:O_COMPRESS:GZIP
 :   : :.tar:/bin/gtar -c -f - %s:T_REG|T_DIR:O_TAR:TAR
 :   : :.tar.Z:/bin/gtar -c -Z -f - %s:T_REG|T_DIR:O_COMPRESS|O_TAR:TAR+COMPRESS
 :   : :.tar.gz:/bin/gtar -c -z -f - %s:T_REG|T_DIR:O_COMPRESS|O_TAR:TAR+GZIP

Any help would be most appreciated.  I will post a summary of replies for
those who might be experiencing similar problems.

TIA,

Cary Talbot

_____________________________________________________________________
Cary A. Talbot, Hydraulic Engineer         US Army Corps of Engineers
ATTN: CEWES-HH-G                         Waterways Experiment Station
3909 Halls Ferry Road
Vicksburg, Mississippi 39180
phone:(601)634-4286   fax:(601)634-4208  email:[email-masked]

---

From: [email-masked] (Dave Wolfe)
Date: Tue, 2 May 1995 12:39:40 -0500 (CDT)

[ Cary Talbot writes: ]
> extensions does not work. [...]

When I had this problem it was because the gzip/gtar executables in
my chroot tree were failing to run. Did you do static links of these
executables or did you copy the necessary dynamic libraries into the
chroot tree? ldd or a similar utility will tell you of all 1st-level
dynamic dependencies.

A similar problem cropped up when gtar was getting errors because it
expected /dev/zero to exist (may have been another /dev node it wanted
as well, but I don't remember now). Try doing a chroot and running the
equivalent command(s) to see if they work that way. I've had it work
when chrooted but not under wu-ftpd, but it does display error messages
that are otherwise lost.

-- 
 Dave Wolfe    *Not a spokesman for Motorola*  (512) 891-3246
 Motorola MMTG  6501 Wm. Cannon Dr. W. OE112  Austin  TX  78735-8598

---

From: Venkatesh Reddy <[email-masked]>
Date: Tue, 2 May 1995 12:18:47 -0500 (CDT)

On Tue, 2 May 1995, Cary Talbot wrote:

> Subject: Compress/Decompress Problems
> 
> Hello:
> 
  I think the binaries "gzip", "gtar", etc. are dynamically linked.
  Execute the command "file gzip" and see if they are dynamically
  linked. If so, you need to create statically linked executables.

Venkatesh Reddy

---

From: Cary Talbot <[email-masked]>
Date: Thu, 4 May 1995 08:44:32 -0500 (CDT)

Original problem:

> > extensions does not work.  

Solution:

By default compress, gzip, and gtar are dynamically linked executables. So
being, you must either recompile them as statically linked or provide the
dynamic link libraries in your ~ftp area (for anonymous servers).  I chose 
the option of recompiling them as statically linked and it the problem has
been solved.  

Many thanks to the two individuals who provided insight into this problem:

Venkatesh Reddy, [email-masked] 
David Wolfe, [email-masked]

---

From: [email-masked] (Dave Wolfe)
Date: Thu, 4 May 1995 10:21:49 -0500 (CDT)

[ Cary Talbot writes: ]
> Many thanks to the two individuals who provided insight into this problem:

You're welcome! Something I forgot to mention in my message was
that Gnu tar, when the z flag is specified, expects to find gzip in
/usr/bin/gzip, so I had to create a symlink in my chroot environment
from /usr/bin -> bin (all my binaries were in /bin), otherwise
retrieving a directory as a compressed tar file, i.e dir.tar.gz or
dir.tgz, fails even though it can be retrieved as just a tar file and
files can be retrieved as compressed files. The whereabouts of gzip
might be a configuration option in gtar, but it's easier to just create
the symlink.