Synchronized browing

Hi,

I upgraded from 4.2.8 to 4.2.9 yesterday (on WinXP) and now the synchronized browing toggle is always off when I start a saved session.
Before, it remembered the status of the last use (I have it always on). Now I have to turn it on, everytime I switch sessions.

Is there a reason for that?

Thanks
Marc

Thanks for your post. This bug has been added to tracker.

I really don't know what is going on here. For 3 years or so I am waiting for the feature that WinSCP remembers the Sync Browse state. I exit the program with that button pressed (on), and when starting again it is off. That has never been different.

Now I see that it (once again) is claimed to be fixed in 4.3.1 beta. Definitely not for me...

Where is WinSCP storing this option and reading it on start?

It was fixed only to pre-4.2.9 state, where the synchronized browsing is re-enabled on start, only if the last component of local and remote path is the same. Is it your case?

martin wrote:

It was fixed only to pre-4.2.9 state, where the synchronized browsing is re-enabled on start

That's what I am waiting for.

martin wrote:

only if the last component of local and remote path is the same. Is it your case?

I don't understand, sorry. I start WinSCP via a link that includes

"C:\Program Files\WinSCP\WinSCP.exe" /ini=t:\WinSCP\WinSCP.ini

t is a truecrypt volume, so my website is protected from unauthorized access.

The ini starts the log-in process to my website, with the local dir in the left pane and the server in the right (NC style), both looking 100% identical. The ini is not write protected and gets a new date after I used WinSCP. What else you need to know?

What are the initial local and remote paths?

Remeber last used dir: unchecked
Remote Dir: /
Local Dir: E:\My Web

noftpanymore wrote:

Remeber last used dir: unchecked
Remote Dir: /
Local Dir: E:\My Web

That's exactly the situation, where it won't work.
It would have to be e.g.:
Remote Dir: /MyWeb
Local Dir: E:\MyWeb

Thanks for your answer, but:

- Is the problem the space in the dir name? I just tried that, seems not.

- Is the probem that the remote dir is only / (root)? But that is quite common IMHO, as the root directory contains lots of files already which need to be there to access the website.

I just don't understand why it is so complicated for users that always (want to) work synchronized to give them exactly that option...

The second is true.

It is not that complicated. It is just not implemented yet.

noftpanymore wrote:

I just don't understand why it is so complicated for users that always (want to) work synchronized to give them exactly that option...

It's been requested here and I think it was also reported before that.

Click Donate and join the club... that feature (I would say that fix) may come sooner that way! :wink:

Hey prikryl,

In 4.3.1 beta you solved 639 which you are referring to this thread. Unfortunatly, you did not fixed the case when root path are not the same. I saw 4.3.2 and now I see 4.3.3 that also fix something related to sync browsing (625) but the case when root path are not the same is still not fixed.

Any hope for next release? Let me quote you...

It is not that complicated. It is just not implemented yet.

:wink:

Just curious... thanks.

Can you please shortly remind me of the scenario you have problem with, so I do not have to read over whole thread again?

noftpanymore wrote:
Remember last used dir: unchecked
Remote Dir: /
Local Dir: E:\My Web

prikryl wrote: That's exactly the situation, where it won't work.
It would have to be e.g.:
Remote Dir: /MyWeb
Local Dir: E:\MyWeb

State of Sync Browse button (on) gets lost when the dir is root. Just make it remember its state / make it work in that situation.

noftpanymore wrote:

State of Sync Browse button (on) gets lost when the dir is root. Just make it remember its state / make it work in that situation.

You mean it is lost, when WinSCP is closed when the dir is root, right?

This is part of:
https://winscp.net/tracker/10

Well... it looks like it was not for this release. :roll:

Next maybe?

Hey ho! Any chance for the bug #10 to be fixed SOON? :?

I just saw 4.3.5 announced on a website, then I come here and see 2 betas, but bug #10 reported a long time ago (2007) is still ignored.

Patience is a virtue! :D

I've raised a priority of this.
But it definitely goes into the 5.x beta branch, not 4.x.