windows ftp server problems

[John Arbash Meinel]

ml.bazaar-ng at donotspam.sent.com wrote:
> This was discussed in the past and I think I have a different problem. 
> I don't know if it's the ftp server causing the problems or if bzr is
> doing something bad.
> 
> The ftp server is filezilla (0.9.22) running on windows (localhost).
> 
> I've attached a log file from the ftp server.
> 
> This is the bzr error:
> C:\projects\pyNetworkTest>bzr push ftp://bzr@127.0.0.1/test
> FTP bzr at 127.0.0.1 password:
> bzr: ERROR: Generic path error:
> '/test/.bzr/repository/knits/1b/pyiperfgraph.py-
> 20061211232559-0y8498yv6noqc1ou-3.knit': could not store: 550 Filename
> invalid)
> 
> Thanks!
> 

My best guess is that we are running into a filename length limitation,
though we seem to be within any sort of windows requirement.

...

> (000010) 12/11/2006 17:44:58 PM - bzr (127.0.0.1)> 227 Entering Passive Mode (127,0,0,1,18,172)
> (000010) 12/11/2006 17:44:58 PM - bzr (127.0.0.1)> STOR /test/.bzr/repository/knits/1b/pyiperfgraph.py-20061211232559-0y8498yv6noqc1ou-3.knit.tmp.1165887898.407000100.2008.145233997
> (000010) 12/11/2006 17:44:58 PM - bzr (127.0.0.1)> 550 Filename invalid


Can you tell us what directory is the root of your ftp server? It seems
we are trying to create a path which is approx 125 characters long.

The filename by itself is 94 characters long.

I thought windows allowed up to 128 characters for any given filename,
and a maximum of 260 for the total path length. So if your directory was
deeply nested (C:\Documents and Settings\Long Username\My Documents\...)
is starting to get pretty long. It is possible that we ran out of
filename space.

At this point, there are a few possibilities, though.

1) Push doesn't actually need to be creating a temporary filename for
this. It is actually using put_bytes_non_atomic(), but the default
implementation falls back to put() which *is* atomic. We can simply
implement put_*_non_atomic() for ftp, similar to how we do it for sftp.
This still leaves us with a file which is 54 bytes long, but that is
better than 94.

2) You can use the sha-hashed knit locations, which I think is a plugin,
if not it is a small patch that is lying around in the mailing list.
Basically, instead of using the file id, we use the sha hash of the file
id. Which gives us something like:
  4021ee6252a8908ffc20dd66da688c143765166e.knit

But that is still 45 bytes, which isn't a big savings over the 54 that
we were using. And without (1) it still ends up as 85 bytes.

3) If it is just because you are running out of total path space, you
could use a different path to host the files. Say C:\public_ftp_site.
The nice thing about this fix is that it is something you can do right
now, without having to change anything about your bzr client.

I did file this bug:
https://launchpad.net/products/bzr/+bug/75422

If it becomes important fix (1) isn't a whole lot of effort (I think we
could re-implement put_bytes_non_atomic() just on top of append(), or a
simplified implementation of put()).

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20061211/7a885ffc/attachment.pgp