Logic bugs in Queue Parent of Selected (FTP File Search)

It looks like it is incorrectly adding information to the queue, the actual folder name is not being appended to the target location, therefor directory structure is lost and all files are sent to the root of where items (in this case folders as the queue parent was used) were queued.

In older versions, using queue selected on a folder correctly sets the target including foldername, and using queue selected on a file correctly sets the target excluding the parent folder name.

In this version, the above circumstances are still true, however using queue parent of selected on a folder incorrectly sets the target excluding the parent folder name (this completely abandons folder structure), and using queue parent of selected on a file incorrectly sets the target excluding the parent folder name and marks the queue item as a file when it should be marked as a folder.

In short, the Queue Parent of Selected option should always mark the queue item as a folder (the parent of any item can never be anything other than a folder), and it should always append the parent foldername to the target field to preserve folder structure.

Bugs present since the introduction of this feature, currently testing with build 1233, windows 2000 pro corp.

Edit :: not sure how i mistakenly marked this as Medium severity, but obviously it should not have been ;s

I'm not entirely sure how we missed these obvious problems.

There are two bugs as you pointed out.

Files weren't being properly switched to folders when queuing.
The folder name isn't appended onto the target location so everything is queued at the base folder.

I sent you a private message with an updated build for testing.

Preliminary tests indicate that both issues have been fixed, i performed a real-world test under circumstances in which i would actually use the feature (and do use the ftp file search for without this particular feature as well) and everything seemed to work correctly.

I also sent in a bug report via the built in bugcheck detection in flashfxp a short time ago, it occured while testing build 1234 for the above fixes. The ftp had idle disconnected, i hit search, hit ok for reconnect, then during reconnection mistakingly hit close in the ftp file search dialog, and the internal bugcheck popped up. This bugcheck occurance was easily repeatable by closing the ftp file search dialog during any stage of reconnection, however the actual bugcheck popup does not display until after the remote site has finished listing.

I hadn't had a chance to review crash reports just yet, but I was able to reproduce that bug and i'll add that to the todo list and get that fixed as well. Thanks

Heh, i only sent it in as i tested the fixes and was posting a reply here, just thought i would explain the circumstances since i was posting already.

k give this one a go,

The crash on closing the ftp search was caused by me accidentally removing a line of code that wasn't documented. It didn't make sense at the time

I also found two other problems.

1. when manually disconnecting from the site during a search would trigger the reconnect attempt. obviously if the user is disconnecting no reconnect should occur.

2. when performing the ftp search the folder changing was erratic and seemed to perform unnecessary folder changes in some situations due to a logic error.

1. Had not noticed this as i tend not to manually disconnect before manually stopping the search as well, but testing shows it does not occur for me with 1235

2. Had also not noticed this, genereally i do something else or walk away while waiting for a search to complete.

Bugcheck reported above seems to be resolved, unable to reproduce.

New path pattern matching seems to work correctly, i noticed one thing but it feels like its intended behavior.

Starting path /tmp/
Match pattern */*i386*/*
Search depth 1

A folder such as /tmp/ca/ca-4.7.X-i386-dist/ is not treated as a match and therefor not listed in the results. Given the way this type of match was described in the pm as listing the contents of the matched folder and the fact that the search depth prevents it from seing the contents, i can assume this is the intended behavior? (just confirming either way)

Nice idea, by the way.

This addition also gave me an idea relating to one of the other FTP File Search feature suggestions i posted in the ftp file search wish list here, details in that thread.

Thats great!

Yah you know thats a very good point, In that case it should match the folder. I will add the logic to support that behavior.