Custom Query (8169 matches)


Show under each result:

Results (490 - 492 of 8169)

Ticket Resolution Summary Owner Reporter
#8305 fixed FileZilla process does not terminate on exit johnnyfv

My install of FileZilla just updated (to 3.6.0). To reproduce the bug: open an SFTP site, exit out of FileZilla, then open Windows Task Manager. Both 'filezilla.exe' and 'fzsftp.exe' remain running.

I call FileZilla from a VBScript, and my program continues only after exiting FileZilla. After installing the latest version, exiting FileZilla did not allow my process to continue.

Opening Windows Task Manager, it became evident that closing the FileZilla interface does *not* halt 'filezilla.exe' or 'fzsftp.exe'; both of these remain resident in memory despite exiting-out of FileZilla.

Opening FileZilla manually and connecting to an SFTP site causes the same behavior. The behavior only manifests if an SFTP site is opened.

#8308 fixed PAPERCUT: "copy" button in "Site manager" panel Aleksandar Kovac

LOCATION: "Site manager" dialog box, bottom-right "Copy" button under the left-hand browser panel.

ISSUE: The function performed by "Copy" button is different from the commonly known "copy" function (from Copy/cut/paste set of commands) which might be confusing to users.

In "site manager", "Copy" button performs "make a copy" or "duplicate" function. In contrast, commonly seen "copy" command performs "copy to clipboard" function.

SOLUTION SUGGESTION: Re-labelling the "Copy" button to: "Duplicate"

OPINION: In common English the verb "to copy" actually fits well the function "site manager's" "copy" button performs (i.e. creating a duplicate or a facsimile), right? But unfortunately, this verb entered computer GUI terminology as short for "copy to clipboard". Beh...

#8309 fixed PAPERCUT: Filezilla user Interface's behavior when a file/directory is dragged onto itself. Aleksandar Kovac

ISSUE: Dragging a file or a folder onto itself in local and remote filelists and tree-views results in inconsistent behavior from FileZilla.

a) Behavior when dragging directories in tree views: REMOTE TREE VIEW: Dragging a directory onto itself in remote tree-view: "Message: A directory cannot be dragged into one of its subdirectories." LOCAL TREE VIEW: "Error 13: permission denied" when dragging a system folder and "Error 22: invalid argument" when dragging a "regular" folder.

b) Behavior when dragging directories in filelists: REMOTE FILELIST: Dragging a file onto itself: "Message: Source and target of the drop operation are identical". Dragging a directory onto itself: "Message: A directory cannot be dragged into one of its subdirectories."

LOCAL FILELIST: Dragging a file onto itself: nothing happens (this is expected behavior). Dragging a directory onto itself: "Error 22: invalid argument" or "Error 13: permission denied", depending on permissions.

SOLUTION SUGGESTION: When a file or directory is dragged onto itself error message boxes don't have to appear at all. Dragging a file or a directory onto itself in any situation should not result in any feedback from from FileZilla. i.e. FileZilla should ignore any attempt to drag a file or a directory onto itself.

RATIONALE: I believe that the suggested behavior is common across many windowed platforms that use tree-views and file lists for file management. Dragging a file onto itself can be considered involuntary or accidental action. This kind of accidental action is especially common with users using pen tablets where a click with the pen tip often is accompanied with some dragging motion.

Additionally, removing the message/error boxes would streamline the interaction for the user a little, and also reduce a couple of GUI points that demand translation and maintenance.

Batch Modify
Note: See TracBatchModify for help on using batch modify.
Note: See TracQuery for help on using queries.