Since the earliest days of Squeak, the FileList has been a great 
utility to fall back on, either when nothing else works, or when you 
don't have other software to do the job.   Until recently, it was 
possible to browse to *any* file on any directory *or server*, copy 
there, browse to another directory, make a file, paste and save.  It 
was consistent and it worked.

Now if you do this with a binary file, as others have observed, the 
thing that gets stored bears almost no resemblance to the original 
file, even though the UI actions boil down to copy-paste.

I was going to complain about this (I have been using an old Squeak 
for a long time for just this reason) except that, using 
drag-and-drop, the right thing happens, and it's actually easier to 
do...

...but only in *some cases*.  What is needed is a little work on file 
drag-and-drop for the case of copying between different devices or 
servers (ie between separate file systems).  Specifically the 
following three fixes would, I believe, restore proper operation in 
this case...

	1.  Recognize this case from the fact that the two 
directories do not have a common root.

	2.  Convert simple drags from 'move' to 'copy' in this case, and

	3.  Do the right thing with file names and directories. 
Naturally the destination name
	should be the local name of the source plus the path name of 
the target directory.

The fact that the FileList can do FTP between servers makes it a very 
powerful tool if other things are working right.  I apologize for not 
having time to do this myself right now, but I think it would be a 
noble service for our shiny new Squeak 3.9 if file drag-and-drop 
could be made to work properly in the FileList.

	- Dan

PS:  To anyone working on this, you will notice considerable delays 
when switching windows open on different servers, and it helps to 
have a Transcript open to understand what is going on.  It would 
probably be nice to figure how to reduce these delays or put up a 
little informer so that normal users will understand that things are 
happening behind the scene.  I think the best solution would be to 
make re-opening the connection a lazy operation, rather than eagerly 
on window wake-up, but we shouldn't let that get in the way of the 
relatively simple fixes above.