[ftputil] mirror script + listing files with dot inside

[Stefan Schwarzer]

Benjamin,

On 2006-12-28 02:18, Benjamin Sergeant wrote:
> On 2006-12-28 01:42, Stefan Schwarzer wrote:
>> The RFC 959 which defines the file transfer protocol tells about
>> LIST but says nothing about a parameter -a , so the effect of
>> this option probably depends on the server or its configuration.
>> A LIST -a _may_ also cause an error and thus an exception, I
>> assume. Therefore, I'm not sure if the complexity of trying
>> LIST -a and possibly falling back to a plain LIST justifies the
>> result of having dirs and files with leading dots included.
>>
>> Even more important may the backward incompatibility if LIST -a
>> is/would be used by default and lists files which "weren't there"
>> with "previous" versions of ftputil. The answer to that may be to
>> make the usage of "LIST -a" optional, which again adds complexity
>> and design decisions regarding if LIST -a should also be used for
>> stat calls and such.
> 
> I understand that it's non standard and not part of the RFC ...
> 
> The other problem I got was this one:
> When trying to remove a dir with rmtree, if the dir contains files
> with dot inside the rmdir fails since the dir is not really empty.

This is to be expected, since rmtree uses listdir (which
uses _dir) internally to select the directories and files
to remove. So the error should not happen if _dir used
LIST -a .

I thought for a moment to let rmtree use the LIST -a variant
of listing a directory; after all the client wanted to remove
the whole directory. But this is dangerous: If someone tests
with listdir for files to keep, the dirs/files with leading
dot won't show up but they would be deleted. Not very
defensive programming. ;-) (Ok, using LIST -a for listdir
would remove that contradiction but, as said, cause backward
incompatibility.)

> ps:
> You can of course use the small mirror function code under the new BSD
> license (it will be probably released under GPL in my pet project,
> http://code.google.com/p/pytof/

Thank you!

Best regards
Stefan