Synchronize Browsing experiences?

[Telcontar]

What does everyone make of Synchronize Browsing?

From what I can see, it's a nice idea, but a suspect implemenation. Being relative only and not based on the initial paths, it trips up in at least two places.

If you create a remote folder and automatically enter it, it will fail to find the same local folder, ditto if you create the local folder first using FlashFXP's local view. As FlashFXP enters the folder, you desynchronise. When you hit Parent Directory to back up, ".." is issued to both views, so one side will go up a level too far now.

Also, if you're browsing a site which has more folders than you do locally, the same problem occurs again: enter one, and leave, and the local view is kicked up a level.

I end up leaving it turned off quite a bit as it really has limited use. Since it also ignores the drop-down menus and address boxes, you can very easily confuse it completely it has no idea where you are. (Selecting remote drop-down history addresses does not switch the local view to what local folder you were in at the time you last visited that remote folder).

This is itself not a feature request, but just wondering whether everyone else has similar views about this feature. I can create my local folder first using Explorer, and remote in FlashFXP so that it doesn't desynchronise, assuming I have the relevant folder window open, else I'd have to go browse to it in Explorer just so I don't screw up synchronised browsing again (takes longer to mess with Explorer than just fix the location).

I'm not sure if there is even a solution to this one?

[DayCuts]

I find Synchronize Browsing quite useful, although i usually use it with hotkey rather than turning the feature on permanently.

I dont see the points you mentioned as 'problems', but i do think they light up some room for improvement.

I think a few new options could be added such as...

Synchronize Commands (for synchronizing the performance of RNFR/RNTO/DELE/MKD/ETC, disabled by default to prevent unintentional use). What happens if it fails on the first side, should it still try on the second? What happens if it fails on the second side, then its desynced again.

Absolute Synchronization (as the name suggests, for synchronizing using absolute paths rather than relative paths) although im not sure how it would handle prefix differences. for example /path/to/www/img/ vs /sub/path/to/www/img/... would it ignore absolute sync and just fall back on relative since they dont match, or would it be prefered to ignore the /sub prefix and process it absolutely.

As for the address bar, i am not sure if/what the best solution would be here, should it mimic changes here? (as part of sync commands maybe?), and if so how should it act if absolute sync was enabled and they dont match? (ie prefix as above example), should it sync automatic changes (selecting from list) or manual changes (typing new path) or both? hmm.

This does bring up another idea though, maybe the temporary sync shortcut key could be designed to work in reverse (not sync for that moment) when synchronized browsing is enable and the shortcut is used?

Now I am wondering how other clients handle this and if they have the same 'issues'.

[Telcontar]

Every time I turn it off, and the server idle disconnects, it gets turned back on when I reconnect. So it would presumably get turned back off if the Site Manager had it off and I'd turned it on. That's a pain.

As far as absolute paths go, I'd go with the pair of root paths in Site Manager. You can set the default local path and default remote path, so you can treat those as being the same. Every sub-path from there on should match. This removes worries about creating a folder or entering a folder that's not present on the other side -- it won't get confused because it knows not to backtrack. I work on a site where I don't have a complete local copy, only those folders which I need locally because they contain my own work. I keep tripping up synchronised browsing every time I open a folder I don't have locally.

When I use the remote address drop-down, I would expect FlashFXP to set the local view to the local folder I was in when I had that remote folder open. That way, I can easily switch between various pairs of folders. My other idea was to have tabs, one tab per local/remote folder pair. Any time a transfer is active in any tab, the rest dim and are queue-only. The program CWDs each time you issue a command in a different tab. With cached directories you can pretty much simulate this (with greater flexibility) with the drop-down, as long as the local list view switches to match, either by remembering where you were, or by using absolute path synchronising from a common root.

I don't know about other FTP clients. FlashFXP is the only decent FTP client I've ever seen for Windows (the rest all suck rocks) and my beloved Mac FTP client (Fetch 3) has no local view at all; it's radically different to FlashFXP but was far more sophisticated in its simplicity, and FlashFXP caught up and overtook it with version 3, for which I was overjoyed. FlashFXP is a nice program.

[bigstar]

I have some thoughts as well. Please let me know what you think.

1. We could define that when "synchronized browsing" is enabled whenever you make a folder locally/remotely it is duplicated on the other active side. Though we could run into problems if the user tried to make a folder locally while a transfer or some other operation is in progress on the ftp side.

2. If you navigate to a folder that doesn't exist on the other side perhaps we should gracefully turn off "synchronized browsing" automatically until the user turns it back on. The other option would be to create the folder on the other side and as above there could be some limitations.

In additon if "synchronized browsing" is off and you want to simply sync. browse on demand hold the ALT key while changing folders and that change will be synchronized.

You can also create paired folder bookmarks, where folder bookmark contains a local and remote path. using the bookmark to jump both sides to a starting place or back to a common location to resume sync. browsing.

I'd really like to support sync. browsing via the drop down box, I have a new idea of how it might be possible with the current design and I'll try to look into that in the next couple days.

[bigstar]

A belated Christmas gift.

Here's a special test build with the the new logic I came up with to handle the dropdown navigation. Please let me know what you think.
http://download.flashfxp.com/beta/ffxp3.5.3.1225.zip

It supports every combination I could think of, However if you're on the local side and change drives obviously the ftp side can't keep up with that.

There may be bugs. Apart from myself no one else has tested this new code and I've only spent about 5 hours on it.

[DayCuts]

• Not sure if this is new... but something i noticed when testing the sb with build 1225 that i had not noticed before... for testing purposes i connected to a localhost ftp and changed local side to the same root (note that not all folders visable on the local side are visible on the remote side while browsing the localhost ftp)
  
  The Unusual behavior is that when entering a folder on the local side, that does not exist on the remote side (ftpd permissions dont allow it to show) the remote side instead performs and CDUP.
  
  [21:41:57] [L] CDUP
  [21:41:57] [L] 250 Directory changed to /c:
  [21:41:57] [L] PWD
  [21:41:57] [L] 257 "/c:" is current directory.
  [21:41:57] [L] PASV
  [21:41:57] [L] 227 Entering Passive Mode (127,0,0,1,6,215)
  [21:41:57] [L] Opening data connection IP: 127.0.0.1 PORT: 1751
  [21:41:57] [L] LIST
  [21:41:57] [L] Connected. Negotiating TLSv1 session..
  [21:41:57] [L] TLSv1 negotiation successful...
  [21:41:57] [L] TLSv1 encrypted session using cipher AES128-SHA (128 bits)
  [21:41:57] [L] 150 Opening ASCII mode data connection for /bin/ls.
  [21:41:57] [L] 226 Transfer complete.
  [21:41:57] [L] List Complete: 59 bytes in 0.02 seconds (3.6 KB/s)
  
  A little further testing shows that this build seems to fall back on this behavior whenever it doesnt find a match. Another test/example was to turn it off, put remote side in /c:/temp/ and local side on C:, turn sb on, then enter 'temp' on the local side. this result in the local side changing to c:\temp and remote side falling back on a CDUP.
  
  Testing to make sure, and this is the same when localhost ftp has locked home directory as to not show the /c:/ root.
  
  I also tested this behavior with two remote servers and the result was the same fallback on CDUP.
  
  
• Ok, on the the topic and changes in question. Havn't noticed any problems or strange behavior when using the dropdown list on the local side (same remote/local test setup), however i did notice some weird behavior when using the dropdown list on the remote side.
  
  I used sb to put both remote and local sides into c:\temp, then entered a folder visible on both sides, then went back to c:\temp, i then used the remote drop down list to re-enter /c:/temp/folder1/, at this point no attempt was made to enter folder1 on the local side even though it did exist.
  
  I tried the same method above with two remote connections and the dropdown list changes were indeed mimic'd however that test was performed with two connections to the same ftp.
  
  When trying this test with two different remote servers some strange behavior was evident.
  
  
• Another scenerio tested was to have two different remote sites connected, L was navigated to /bin/tmp/ and right in root /, using the L dropdown list to change back to /bin/ resulted in R side falling back on a CDUP, even though /bin/ existed on the R side (and it was present in the R side dropdown list as it had been previously visited)
  
  
• More tests.. L in /bin/tmp/ R in /bin/tmp/rsc/ editing drop down list manually to change L to /bin/ results in L issuing CWD /bin/ and R issuing CWD /bin/tmp/... not sure if this is intended behavior or not (its counting the number of levels up and mimicing that amount on the other side?)
  
  
• L in /bin/tmp/ R in /, use dropdown list to change to /bin/, result is R side attempting a CDUP when already in root (intended or fallback bug? no need to attempt cdup when known to be in root if intended)
  
  
• L in /bin/ R in / (/bin/ exists), change L to /bin/tmp/ with dropdown list, R side attempts a CWD /tmp/ which of corse fails.
  
  Not sure how all of this is supposed to act, and which tests may depict bugs and which are just because L and R are out of sync to begin with, but thought i'd ramble with as much detail as possible.

PS. Just incase the post was missed because i think a new build was out by the time i posted, but i posted in the thread for build 1222 here about some bugs related to the new feature added to the FTP File Search.

[bigstar]

DayCuts,

It would appear that if the folder doesn't exist remotely based on the listing then the folder was set as "", when syncing "" is equal to CDUP which is why this occurred.

I've decided to change this and attempt to change folders regardless of if the folder exists in the listing as it may have been created and the cache is out dated. Also if the folder simply doesn't exist it won't do a CDUP. though it will still break sync browsing.

Also this behavior existed since sync. browsing was first added.

I did some tests where one site root was / and the other was /temp/ as root and as far as I could tell everything seems to be working fine. Although I did these tests after making the above change so that may be a factor, I'm not 100% sure.

I'll be posting a new build to beta testers today with the above mentioned change, Please give it a try and let me know if you notice any other oddities.

[DayCuts]

Originally Posted by bigstar

Also this behavior existed since sync. browsing was first added.

I dont think this is accurate, i just tested this with with the 3.4 final because i was sure this had never been the case before. I was right, 3.4 final does not fall back on a CDUP at all, if you attempt to enter a folder (either locally or remotely) and this folder does not exists on the other side then that side does nothing at all.

Personally i think this is the preferred behavior and should be put back, i dont think falling back on a CDUP is wise and im not sure attempting to enter the directory is desired either. I dont use SB that much compared to some others so maybe they have a better informed (for lack of better word) opinion on the matter, but it worked fine before and im not sure there is any reason to change it.

Will check out the new build shortly.

[DayCuts]

Point 1: Posted above.

Point 2: Partially fixed.

Again when using the remote dropdown list to reenter a folder that had previously been visited no attempt to enter that folder on the local side is made (again it does exist and should logically reenter this folder), this is regardless of the path depth in question.

This behavior no longer occurs when dealing with two different remote servers, the dropdown list is now successful is switching paths on both sides (this was broken in build 1225)


Points 3+4: Same behavior exists as described above, just to confirm is this the desired behavior (counting the number of path levels to move up)


Point 5: Same behavior exists, performing the unnecersary CDUP on side R when it is already in root /. Again was this the intended behavior (as its just counting one uplevel and issuing the CDUP to mimic that), maybe it should notice that its in root / and skip the CDUP rather than performing needless tasks?


Point 6: Same behavior exists.

Is this the new designed behavior (3.4 final made no attempt to change side R at all under these circumstances, non dropdown list use of corse as it did not exist, as with Point 1, i am not sure if this is should be the preffered behavior)

Little futher note about this particular point, the command sent is different when using the dropdown list than when doing it by clicking. When click side L into /bin/tmp/ (from /bin/) side R sends "CWD tmp", while when using the dropdown list to perform the same task, side R sends "CWD /tmp"... one is synchronizing in relative paths while the other is using absolute paths making the behavior a little inconsistant.


Finnal views: It seems that when adding support for SB through the dropdown list (or maybe in earlier betas and i missed it?) that some of the behavioral logic with the already existing click navigation method of SB were altered.

Personally i think that the old click style navigation method should not have been changed, i believe the logic and efficiency of how things worked before was best (more sound and concistant)

IMO, the new dropdown list support for SB should not have changed the old click style SB behavior (why change what was not broken), and should have instead mimic'd the existing click style SB behavior as much as possible (not falling back on CDUP or CWD commands that will knowingly fail (or be mute) 99% of the time).

[bigstar]

On friday I discovered and resolved a issue regarding slashes, sometimes it would leaveout or double up the slashes preventing the change to occur, especially locally.. i.e. C:\windowssystem\ instead of C:\windows\system.. This has been resolved.

SB doesn't check to see if you're in root before issuing a CDUP, I suppose for situations where root is / or \ then we can check for this and simply do nothing.

all SB changes need to be relative to a similar point on both sides. If one side is / and the other is /bin/ and you want to change into /bin/tmp then you'll end up with /tmp on the other side. this is the desired effect based on the design, although it may be an unexpected result.

SB via the listview only needs relative paths, SB via other methods require absolute paths for most changes, we could mix absolute and relative paths for some path changes but I'm not sure if this is such a big deal, it just adds to the complexity of the methods.

As far as the other issues you've encountered I have not experienced or been able to reproduce them, though they may be related to the above mentioned bug fix.

Finnal views: It seems that when adding support for SB through the dropdown list (or maybe in earlier betas and i missed it?) that some of the behavioral logic with the already existing click navigation method of SB were altered.

I'm not sure what you're referring to here, none of the original logic has changed apart from removing a check that made sure a folder existed before trying to change to it, however that was removed because a folder may exist but the listing cached and simply not see it.

IMO, the new dropdown list support for SB should not have changed the old click style SB behavior (why change what was not broken), and should have instead mimic'd the existing click style SB behavior as much as possible (not falling back on CDUP or CWD commands that will knowingly fail (or be mute) 99% of the time).

I'm not entirely sure what you're referring to here. Are you saying that you'd rather SB via dropdown use CDUP when needed instead of absolute paths, or use CWD ../../myfolder instead of /path/to/myfolder when possible?


Edit: The more I use SB the more I feel that perhaps SB should simply disable if a path change can't be sync'd.
I'd love to extend the option and features in future versions, we simply ran out of time for this release.

[DayCuts]

On friday I discovered and resolved a issue regarding slashes, sometimes it would leaveout or double up the slashes preventing the change to occur, especially locally.. i.e. C:\windowssystem\ instead of C:\windows\system.. This has been resolved.

Nice, hopefully this is the source and fix for the broken local sb behavior.

SB doesn't check to see if you're in root before issuing a CDUP, I suppose for situations where root is / or \ then we can check for this and simply do nothing.

This seems like a more appropriate method to me, while some servers report an error on cdup in root, others (most cases) just refresh the listing of the current folder which can take some time if its large or the server is slow.

all SB changes need to be relative to a similar point on both sides. If one side is / and the other is /bin/ and you want to change into /bin/tmp then you'll end up with /tmp on the other side. this is the desired effect based on the design, although it may be an unexpected result.

SB via the listview only needs relative paths, SB via other methods require absolute paths for most changes, we could mix absolute and relative paths for some path changes but I'm not sure if this is such a big deal, it just adds to the complexity of the methods.

Indeed, just confirming the behavior was intentional.

As far as the other issues you've encountered I have not experienced or been able to reproduce them, though they may be related to the above mentioned bug fix.

I'm starting to loose track of which is which ha, i think you have covered/explained/fixed most (if not all) of it already, so i will just check again with the next build.

I'm not sure what you're referring to here, none of the original logic has changed apart from removing a check that made sure a folder existed before trying to change to it, however that was removed because a folder may exist but the listing cached and simply not see it.

For the most part i was just refering to this changed behavior.. when no match is found, i see now why you chose to make this change. Maybe this check and behavior can be dependant on weather caching is enabled or not (for the side its checking), and of corse if the folder is actually cached (may not be cached yet if caching has only just be turned on, meaning the list is already fresh). When the list is fresh (caching off or current list not cached) do nothing, when its cached and caching is enabled attempt the folder change.

I'm not entirely sure what you're referring to here. Are you saying that you'd rather SB via dropdown use CDUP when needed instead of absolute paths, or use CWD ../../myfolder instead of /path/to/myfolder when possible?

No, it just seemed weird/unusual behavior. However i think its just another one of those things brought about by the shear complexity and of SB as a whole.


Anyway, Will test again to confirm the slashes bugfix was responsible for the local sb issue etc, otherwise i think for the most part everything that seemed strange/unexpected has been covered.

[Telcontar]

Weird. Presumably due to the site move, nothing until the most recent post got mailed to me, just now, so I didn't realise you'd posted a new version. It looks interesting

Then again, by the sounds of it, it might make more sense to try a new build rather than the one posted, since bugs have been fixed?

[bigstar]

I sent both of you a private message, check it out

[Telcontar]

Well, I logged into the site I manage with FlashFXP, which took me to the local and remote folders. On the local site, there's a folder called "New Folder" that I forgot why I put it there, so I opened it. FlashFXP tried to open the remote folder even when the listing hadn't indicated it existed; the server responded "550 New Folder: No such file or directory".

I then double-clicked Parent Directory in the local view to return to the root. The remote side then CDUP'd out of the site root into the parent folder. This is the precise behaviour that makes Synchronize Browsing so frequently untenable. I don't have the entire site on my PC here (it's pretty huge), and there will always be mismatches.

I confirmed earlier though with build 1225 that switching folder using the address bar (either by typing or by selecting a recently-visited remote folder) does now synchronise both sides correctly, which is great.

As far as folder creation goes, one possibility is to have a tickbox in the New Folder dialog that says, "Create matching folder in $other_view" to bypass the desynchronisation problem of creating a folder one side at a time. Although you can resolve it using Explorer for local-remote, this would also solve the problem for people doing FXP. That said, I have FlashFXP set to enter a new folder on creation which may possibly be wrong to begin with -- might be easier to turn that off and create a folder on each side manually?

[DayCuts]

Originally Posted by DayCuts

I used sb to put both remote and local sides into c:\temp, then entered a folder visible on both sides, then went back to c:\temp, i then used the remote drop down list to re-enter /c:/temp/folder1/, at this point no attempt was made to enter folder1 on the local side even though it did exist

As far as i can tell the bugfix you found and made relating to slashes has resolved this problem, i have been unable to reproduce this with the latest beta.

Originally Posted by Telcontar

The remote side then CDUP'd out of the site root into the parent folder.

Do you mean the server actually let you CDUP from root / into the parent folder? (i have never seen this before, if server shows / at root it means your locked in home dir otherwise it shows absolute paths)... or do you mean it took you up one level out of your saved 'remote path' for that site?