Custom Query (8025 matches)
Results (133 - 135 of 8025)
|#191||GSS Login fails with username no warning|
If you go to the site manager and connect to a site defined as 'use GSS' (*.mit.edu for example) it connects if you have Kerberos tickets, or gives you an "Are you sure you want to send password in the clear" dialog if you don't have tickets. However, if you have tickets and enter a different username to connect with, it just asks for your password with no 'no tickets' warning. Entering a password yields an Error: could not retrieve directory listing. It then remains connected and periodically gives a 530 Please log in with USER and PASS .
|#192||error in remote directory|
I want to connect with a FTP server on a Windows machine. The defaut remote directory is like : "D:/path/to/my/directory" (i can't change it, it's a server of a provider)
but Filezilla add a "/" to this remote directory
When i want to download a file "file", filezilla send to the server : "/D:/path/to/my/directory/file"
and CWD failed because the server don't understand the directory name...
download works with other FTP clients like WSFTP or CuteFTP.
I think thaht in this case you must not add a "/" to the remote directory
|#193||Executable files from Solaris servers|
I've connected to 2 or 3 different Solaris servers and have noticed the same problem on all of them: any executable files in the file listing have an asterix at the end of the name, for example: myscript.pl*
It is of course normal to see an asterix following files that have the execution bit set, since this is the way ls will often display such files, so that they can be quickly identified in a long listing.
However, the fact that the asterix is appearing in the Filezilla listing seems to confuse Filezilla, since any attempt to download these files will fail.
The following is an example of the error I'm describing, pulled from the filezilla log window:
Command: GET myscript.pl* c:\myscript.pl* FALSE Response: /www/cgi-bin/myscript.pl*: no such file or directory Error: Download failed
In general Filezilla is a great tool, but the only work around I've found for this is to temporarily turn off the executable bit using CHMOD ... which is not very handy to say the least, but necessary if I want to get at these files.
I have not seen this problem on Linux boxes, only Solaris.