Opened 15 years ago

Last modified 15 years ago

#613 closed Bug report

local non-windows network drive kills Filezilla

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

Description

Versions tested with problem: 2.2.5.100, 2.2.4.600

Environment: W2kSP4 running under VMWare Workstation 4

When browsing local filesystem, if you select a drive
mapped to a VMWare share, a box pops up saying "The
parameter is incorrect". For the rest of your session,
the local file list box is grey and empty (but the
treeview control continues to function). Upon exiting
Filezilla, you will no longer be able to run it; when
you attempt to execute it, there will be brief
drive/processor activity, but no process appears in the
task manager.

Examination of Filezilla.XML shows the following value:

<FileZilla>

<Settings>

<Item name="Default Folder" type="string">M:\</Item>

...where M: is the offending drive. Changing M: to C:
allows Filezilla to work again.

Background on VMWare shares:
VMWare allows the host to share folders, in much the
same way as Windows Networking. In the guest OS, they
appear as network shares & behave pretty much the same
way. In the virtual machine, The Windows network view
shows the following:

Entire Network

Microsoft Windows Network

workgroup_name

machine_name

share_name

VMWare Shared Folders


.host


.host\share_name

VMWare shares can be mapped to a drive letter and used
the same as any other network share.

I don't know if this same problem occurs in other types
of filesystems outside of the VMWare environment or
not, but suspect it might...

Change History (1)

comment:1 Changed 15 years ago by Tim Kosse

This problem is not caused by FileZilla. The Windows
functions for accessing files and folders itself are bugged.
That why I suggest everyone to use FTP to transfer files
instead of using the windows shares.

Note: See TracTickets for help on using tickets.