Custom Query (7774 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (10 - 12 of 7774)

1 2 3 4 5 6 7 8 9 10 11 12 13 14
Ticket Resolution Summary Owner Reporter
#4908 rejected z/os uss directory/file errors Steve Mann
Description

Problems with FileZilla client 3.2.8.1 and z/OS USS directories and files. These happen with servertype set to "default(autodetect)" or "MVS, OS/390, z/OS" in SiteManager.

If I issue a change directory for USS in z/OS, the FileZilla changes the second or later / to a . in the directory name.

Command: CWD '/etc' Response: 250 HFS directory /etc is the current working directory Command: PWD Response: 257 "/etc" is the HFS working directory.

Command: CWD msussl Response: 250 HFS directory /etc/msussl is the current working directory Command: PWD Response: 257 "/etc/msussl" is the HFS working directory.

At this point I really am in directory /etc/msussl but it displays in FileZilla as /etc.msussl

File transfers are also being messed up. Sending a file to /etc/msussl should end as /etc/msussl/file but FileZilla is sending it as /etc.msussl(file).

Command: STOR '/etc.msussl(CA.der)' Response: 125 Storing data set /etc.msussl(CA.der) Response: 250 Transfer completed successfully.

Retrieving a file does this also. This should have been retrieving file /etc/msussl/CA.der

Command: RETR '/etc.msussl(CA.der)' Response: 550 Command RETR fails: /etc.msussl(CA.der) does not exist. Error: Critical error

#8224 duplicate z/VM: Unable to analyze the returned directory Alain
Description

Hi,

FileZilla Client


Version: 3.5.3

Build information:

Compiled for: i586-pc-mingw32msvc Compiled on: x86_64-unknown-linux-gnu Build date: 2012-01-08 Compiled with: i586-mingw32msvc-gcc (GCC) 4.2.1-sjlj (mingw32-2) Compiler flags: -g -O2 -Wall -g -fexceptions

Linked against:

wxWidgets: 2.8.12 GnuTLS: 2.10.4

Operating system:

Name: Windows NT 6.1 (build 7601, Service Pack 1) Version: 6.1 Platform: 64 bit system

Statut : Connexion à 192.168.1.100:21... Statut : Connexion établie, attente du message d'accueil... Réponse : 220-FTPSERVE IBM VM Level 540 at PHOENIX.dassault-aviation.co, 14:27:57 EDT SATURDAY 2012-09-08 Réponse : 220 Connection will close if idle for more than 5 minutes. Commande : USER anonymou Réponse : 230 ANONYMOU logged in; working directory = /../VMBFS:DWSYS:ANONYMOU/ Statut : Connecté Statut : Récupération du contenu du dossier... Commande : PWD Réponse : 257 "/../VMBFS:DWSYS:ANONYMOU/" is working directory Erreur : Impossible d'analyser le chemin retourné. Erreur : Impossible de récupérer le contenu du dossier

With a previous version of filezilla we have at work, I can do what I want. Now with this one from home I can't... The deal is to send windows files to a z/VM mainframe. The target is BFS file architecture.

Able to test/send anything you ask me.

Regards Alain

#4542 wontfix z/VM: Failed to parse returned path. Mark Cibula
Description

After successful login to a z/VM 530 (or higher level) FTP server, no directory listing is obtained. This error occurs regardless of the list format setting of the /VM host (which can be either 'VM' or 'UNIX') or of the client Site Manager "Advanced" tab 'Servertype' setting (both 'z/VM' or 'default (Autodetect)' yield the same failure. A log showing this error follows:

14:22:39 Trace: CControlSocket::DoClose(64) 14:22:39 Status: Connecting to 9.xx.xx.xx:221... 14:22:39 Status: Connection established, waiting for welcome message... 14:22:39 Trace: CFtpControlSocket::OnReceive() 14:22:39 Response: 220-FTP BANNER for TCPIP04.VMxxx.xxxxxxxx.xxx.xxx 14:22:39 Trace: CFtpControlSocket::OnReceive() 14:22:39 Response: FTPSRV04 IBM VM Level 530 at VMT1.xxxxxxxx.xxx.xxx, 14:21:49 EDT MONDAY 2009-06-01 14:22:39 Trace: CFtpControlSocket::OnReceive() 14:22:39 Response: 220 Connection will close if idle for more than 5 minutes. 14:22:39 Trace: CFtpControlSocket::SendNextCommand() 14:22:39 Command: USER TCPMNT04 14:22:39 Trace: CFtpControlSocket::OnReceive() 14:22:39 Response: 331 Send password please. 14:22:39 Trace: CFtpControlSocket::SendNextCommand() 14:22:39 Command: PASS 14:22:39 Trace: CFtpControlSocket::OnReceive() 14:22:39 Response: 230-TCPMNT04 logged in; working directory = TCPMNT04 191 (ReadOnly) 14:22:39 Response: 230 write access currently unavailable 14:22:39 Status: Connected 14:22:39 Trace: CFtpControlSocket::ResetOperation(0) 14:22:39 Trace: CControlSocket::ResetOperation(0) 14:22:39 Trace: CFileZillaEnginePrivate::ResetOperation(0) 14:22:39 Status: Retrieving directory listing... 14:22:39 Trace: CFtpControlSocket::SendNextCommand() 14:22:39 Trace: CFtpControlSocket::ChangeDirSend() 14:22:39 Command: PWD 14:22:39 Trace: CFtpControlSocket::OnReceive() 14:22:39 Response: 257 "TCPMNT04.191" is working directory (ReadOnly) 14:22:39 Trace: ControlSocket.cpp(361): Failed to parse returned path. caller=0p152b050 14:22:39 Trace: CFtpControlSocket::ResetOperation(2) 14:22:39 Trace: CControlSocket::ResetOperation(2) 14:22:39 Trace: CFtpControlSocket::ParseSubcommandResult(2) 14:22:39 Trace: CFtpControlSocket::ListSubcommandResult() 14:22:39 Trace: state = 1 14:22:39 Trace: CFtpControlSocket::ResetOperation(2) 14:22:39 Trace: CControlSocket::ResetOperation(2) 14:22:39 Error: Failed to retrieve directory listing 14:22:39 Trace: CFileZillaEnginePrivate::ResetOperation(2)

The transfer type is FTP (no SSL/TLS security involved). No 'Default remote directory' is specified with the Site Manager 'Advanced' box.

After having specified such default remote directory as '/tcpmnt04.191', the described error does not occur (and, the leading slash (/) is critical in this regard; in fact, specifying a single '/' as the remote default directory appears to alleviate this problem.

The leading '/' is not part of the z/VM file system structure, and seemingly should not be required to be specified as a remote directory default, especially for the case when 'z/VM' (specifically) is designated as the (remote) servertype.

1 2 3 4 5 6 7 8 9 10 11 12 13 14
Note: See TracQuery for help on using queries.