#761056 Can't use long pathnames with some(?) FTP servers

Package:
sitecopy
Source:
sitecopy
Description:
program for managing a WWW site via FTP, SFTP, DAV or HTTP
Submitter:
Roman Mamedov
Date:
2014-09-10 14:21:18 UTC
Severity:
normal
#761056#5
Date:
2014-09-10 10:44:11 UTC
From:
To:
Hello,

If I try to upload a site where a file named longer than 79 characters exists,
it will upload the file giving it an incorrect name it on the server: cutting
the name short at 79th character.

On subsequent fetch+upload cycles it will delete the incorrectly named file,
then proceed to upload it again, once more under the same cut-off name. This
will repeat indefinitely.

For testing I manually created a file on the FTP server with a name longer
than 79 characters. After this sitecopy can no longer successfully fetch such
website, with the error "550 Can't check for file existence."

Looks like somewhere the FTP filenames are incorrectly chopped to 79 (perhaps
80, with the trailing #0) bytes.
Debian Release: 7.6
  990 stable          www.emdebian.org
  990 stable          approx.home.romanrm.net
  100 wheezy-backports approx.home.romanrm.net
--- Package information. ---
Depends               (Version) | Installed
===============================-+-===========
libc6                (>= 2.3.4) | 2.13-38+deb7u4
libneon27-gnutls                | 0.29.6-3


Package's Recommends field is empty.

Package's Suggests field is empty.

#761056#10
Date:
2014-09-10 13:37:34 UTC
From:
To:
retitle 761056 Can't use long pathnames with some(?) FTP servers
thanks

Hello,

Sorry, after some more testing the limitation appears to be of a different
nature: a total length of path+filename maximum of 198 characters, that can
be passed in one command.

For testing I have now created a directory on the FTP server, named as (without
spaces):
012345678900123456789001234567890012345678900123456789001234567890012345678900123456789001234567890012345678900123456789001234567890012345678900123456789001234567890x

And inside it, a file named:
01234567890012345678900123456789001234567890012345678900123456789001234567890z

Trying to get the modification time of that file "in one go":

ftp> cd /
250 OK. Current directory is /
ftp> quote MDTM /012345678900123456789001234567890012345678900123456789001234567890012345678900123456789001234567890012345678900123456789001234567890012345678900123456789001234567890x/01234567890012345678900123456789001234567890012345678900123456789001234567890z
550 Can't check for file existence

This is the same error that sitecopy is hitting.

But, if I first 'cd' into the long-named directory and then issue MDTM with a
shorter argument (just the filename), it works:

ftp> cd 012345678900123456789001234567890012345678900123456789001234567890012345678900123456789001234567890012345678900123456789001234567890012345678900123456789001234567890x
250 OK. Current directory
is /012345678900123456789001234567890012345678900123456789001234567890012345678900123456789001234567890012345678900123456789001234567890012345678900123456789001234567890x
ftp> quote MDTM 01234567890012345678900123456789001234567890012345678900123456789001234567890z
213 20140910132003

Unfortunately sitecopy seems to issue its file operations with absolute
pathnames, which end up being too long for (this particular?) server to
handle, and that's what is causing the problem.

I wonder if this is just a limitation of my provider's particular FTP server.

Regardless, it'd be nice to have a mode where sitecopy would 'cd' into
directories one by one, to allow for a longer total pathname than the FTP
server has decided to allow fitting into one command argument.

"ftp usecwd" option seems to be very close, but it does not affect how MDTM is
issued during fetch (and for the above example to work, it must be issued only
on files in the current working directory too).