Opened 14 years ago

Last modified 5 years ago

#3021 closed Bug report

Filezilla confused by unix search-only directories

Reported by: ted_dustman Owned by:
Priority: normal Component: Other
Keywords: Cc: ted_dustman, Alexander Schuch, Tim Kosse
Component version: Operating system type:
Operating system version:


Using ftp, filezilla (2.2.14.a) gets confused when it
encounters directories with search-only permissions,
e.g.: rwxr-x--x and rwxr-x-wx.

In my case the ftp server is vsftp on OSX 10.3.9.
Other clients handle this correctly, like Cyberduck
(OSX) and the unix ftp command-line client.

Here are some more details on the directory structure
and operations that cause filezilla to fail:


where * represents a collection of directories under
cvrti. The cvrti directory has permissions rwxr-x--x,

  • directories have permissions rwxr-xr-x, Upload is

rwxr-x-wx and Download is rwxr-xr-x. Note that I don't
want the contents of cvrti or Upload to be visible.

I can get Filezilla to cd into a * directory and from
there I can retrieve files from the Download directory.

But I can't put files to the Upload directory.

Attachments (1)

filezilla-debug-log.txt (3.3 KB) - added by ted_dustman 13 years ago.
FileZilla level 3 debug log

Download all attachments as: .zip

Change History (11)

comment:1 Changed 13 years ago by Alexander Schuch

Can you please re-try with current FileZilla 2 or FileZilla
3 beta?

comment:2 Changed 13 years ago by ted_dustman

Both current 2.x and 3 beta are broken, even worse than
before. Now I can't even cd into a * directory nor can I cd
directly into cvrti/*/Download. Here again are the perms
(for cvrti/*/Upload or Download):

drwxr-x--x cvrti
drwxr-xr-x *
drwxr-xr-x Download
drwxr-x-wx Upload

FileZilla acts like it's applying the perms for cvrti

Thanks, T.

comment:3 Changed 13 years ago by Alexander Schuch

Is it possible for you to supply a test account? If you do
not want to give the account details in public here, you can
either mark this report as "private" or send the
test-account login information to my e-mail address.

comment:4 Changed 13 years ago by Tim Kosse

Please attach some logs showing the problematic behaviour.

The logs should be made using debug level 3 which can be enabled
on the debug page in the settings dialog of FileZilla.

The logs have to be complete and unmodified. Do not attempt to
remove or obfuscate any information you might find irrelevant.

If you are worried about posting IP addresses or other
confidential information, mark the tracker item as private.

comment:5 Changed 13 years ago by Tim Kosse

What is a "search-only" directory?

Changed 13 years ago by ted_dustman

Attachment: filezilla-debug-log.txt added

FileZilla level 3 debug log

comment:6 Changed 13 years ago by ted_dustman

A search-only directory is one that can be entered but whose
content cannot be listed, e.g.

drwxr-x--x cvrti

Directory cvrti is search-only for anonymous users (--x).
Cvrti can be entered but it's content cannot be listed.
This doesn't seem useful but it forces clients to specify a
sub-directory within the cvrti directory. Thus I would ask
you to connect to (anonymous-only site)
and specify the directory /cvrti/dustman. You can't get
there and you should be able to.

It seems FileZilla is not seeing that it can 'pass through'
the cvrti directory into the dustman directory.

I've attached a debug log when attempting to go to
/cvrti/dustman. Feel free to try yourselves.



comment:7 Changed 13 years ago by Tim Kosse

Command: CWD /cvrti/dustman/
Response: 250 Directory successfully changed.
Command: PWD
Response: 257 ""

The server has a broken PWD implementation, that's why
FileZilla fails. Not sure if I can work around this problem.

comment:8 Changed 13 years ago by Alexander Schuch

Using the console FTP from FreeBSD (Version: NetBSD-ftp 20050514), I get the same problem:
ftp> cd cvrti
250 Directory successfully changed.
ftp> pwd
Remote directory: /cvrti
ftp> cd dustman
250 Directory successfully changed.
ftp> pwd
Unable to determine remote directory

comment:9 Changed 13 years ago by Tim Kosse

I wonder which implication path assumption has on the
directory cache. Just constructing the new directory locally
and then assuming it got changed into it. I forsee problems
with symbolic links, especially on servers that don't mark
links as such.

comment:10 Changed 13 years ago by Tim Kosse

I've done some changes to work around this problem. The
changes will be available from the 2006-10-26 nightly onwards.

Note: See TracTickets for help on using tickets.