Post a reply

Before posting, please read how to report bug or request support effectively.

Bug reports without an attached log file are usually useless.

Options
Add an Attachment

If you do not want to add an Attachment to your Post, please leave the Fields blank.

(maximum 10 MB; please compress large files; only common media, archive, text and programming file formats are allowed)

Options

Topic review

martin

OK, I can finally reproduce that. Thanks :-)
TS

So a bit more investigation.

On Vista, this behavior is the same in 4.0 and 3.8.2. (I've just never bothered with logging before now.) You try to put the log file on your desktop, and it just doesn't work. In the selection dialog, you select desktop and click open, then the dialog reverts to the C:\Users\<username> directory instead, and stays open. You can select desktop and end up in c:\users as many times as you like, but if you click open from the C:\users\<username> it seems to work correctly.
However in Vista, with 4.0 if you select (or type into the dialog) C:\temp\&s.log it ignores the selection dialog's result and the filename field (after the selection dialog exits) remains in the default location of local settings. With 3.8.2 when I select C:\temp\&s.log, the filename field changes.

On Server 2003 EE SP2 with 4.0 you can select desktop and click open and the dialog box closes (like you would expect) but the filename field does not update. Same behavior trying to select c:\temp\&s.log. Both cases work as expected (i.e. the filename field updates) with 3.8.2.

The behavior of XP SP2 is identical to that of 2003EESP2.
martin

Re: Log file selection dialog nonfunctional

I cannot reprocuce the problem. What version of WinSCP are you using? What OS? What path do you select? What path is selected before you change it?
TS

Log file selection dialog nonfunctional

When logging to a file (debug lev 2 if it matters), the "..." button that supposedly allows one to browse for a directory/file location silently fails. Browsing and selection work fine, but the text of the log file field is never actually updated. If one ignores the "..." button and types/pastes in a location, it seems to work as expected.

This behavior doesn't seem specific to one computer or OS.