Opened 21 years ago
Last modified 21 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...
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.