Possible Site Manager Bug

[chip]

Hi,

I'm using v2.0 RC2 Build 867.


1) Connect to a site in your site db.
2) Got to Site Manager and move this connected site to a different group. Save changes.
3) Que a file, and attempting to normally transfer files on the connected site results in:

>Error: "Connected Site" not found in Site Manager
>Transfer queue completed

4) Disconnect from site, and "reconnect", and retry of the transfer que fails again.
5) Disconnect from site, clear the transfer que, "reconnect", and retry of the transfer que fails again.
6) Remedy Found: clear que, disconnect site, manually reconnect using the site manager.

When I refer to "reconnecting" in step 4 and 5, I am referring to the quick "Reconnect: Site Name" option using the connection icon on the option bar.

I believe this is a functionality miscalculation?

chip warner
chip@skidmonk.com
software designer
www.skidmonk.com

[bigstar]

Queue files are link to the site manager based on location/name, if you move or rename a site you break the link.

This could be considered a design limitation. This is how it works, and I don't see it changing any time soon.

Once the link is broken you can relink a queue item with the site by right clicking the queue item and selecting edit from the menu, now select the newly named/moved site.

[chip]

1) Once you disconnect, from a site who's location/name has recently changed in the database, shouldn't "reconnecting" be affected by this limitation as well?

2) Its not, so if the site can be "found" to reconnect, which means the site infomation is stored in memory, shouldnt you be able to transfer files then as well?

Regardless, I believe you should be able to detect if the site name/location was changed as soon as you que'd files, correct?
When this happens, it doesn't seem like it would be hard to apply a quick functionality fix, possibly prompt for the new site location/name?

kindly,
chip warner

[bigstar]

Originally posted by chip
1) Once you disconnect, from a site who's location/name has recently changed in the database, shouldn't "reconnecting" be affected by this limitation as well?

When you reconnect using the "reconnect to" feature some of the information is kept in memory and no validation is done to insure the site exists in the site manager.

2) Its not, so if the site can be "found" to reconnect, which means the site infomation is stored in memory, shouldnt you be able to transfer files then as well?

no, as stated above. Not all information is stored in memory, when transferring files some of this information that is required isn't availible.

Regardless, I believe you should be able to detect if the site name/location was changed as soon as you que'd files, correct?
When this happens, it doesn't seem like it would be hard to apply a quick functionality fix, possibly prompt for the new site location/name?

If the files were queued and then the site was renamed/moved then maybe something could be done. I will look into this.

The user isn't prompted for the new site because the site may have been deleted, also I think most users wouldn't have a clue as to what just happened and why the site wasn't found in the first place. Which is why I recommend editing the queue items as explained above.

[bigstar]

If the "reconnect to" is updated after a rename/move this problem seems to be resolved.

If the loaded queue file is updated when a rename/move is performed it seems to elevate most of the problems.

The only issue that remains is with queue files that are not loaded when a rename/move is performed.

[chip]

Originally posted by bigstar
If the "reconnect to" is updated after a rename/move this problem seems to be resolved.

I was thinking, if a simple validation was performed when "reconnect to" was used, and when it detects that this current site was moved/renamed/deleted, wouldnt most of the problems be solved if Flash quickly added it to cache as a "Quick Connect" site, and continued as normal? Or, as you stated in your previous post, is there not enough information stored in memory to treat this new homeless site, as a "Quick Connect"?

There would be the problem with any files if they were previously que'd, but when this validation occurs, I suppose maybe you could prompt the user informing that the old que will need to be cleared, or need to manually update the que'd file's "site". I suppose that would clear up any confusion if this random limitation ever effects anyone else.

[I wasn't sure if this post of mine is what you were implying in your quote above, but I appologize if I am being redundant.]

cheers,
chip