Bug: Vista UAC Interfering with Drag-and-Drop

Advertisement

kyboren
Joined:
Posts:
3

Bug: Vista UAC Interfering with Drag-and-Drop

I'm running WinSCP 4.1.8 (Build 415), using SFTP-3 and the Norton Commander interface.

When I try to drag a file from the remote server pane to either the local machine pane or an external Explorer window, if the destination directory is protected by UAC (e.g. a folder in Program Files), the operation fails with a message, "A call to an OS function failed," or occasionally "System Error. Code: 5.\nAccess is denied."
In the case of the first error message, no file is created. With the latter, a .filepart file is created (with the same file size as the file I tried to copy, though I haven't checked if it really contains all the data of the source file).

If I run WinSCP in UAC-elevated mode, the file transfers just fine.

Reply with quote

Advertisement

martin
Site Admin
martin avatar
Joined:
Posts:
40,476
Location:
Prague, Czechia

Re: Bug: Vista UAC Interfering with Drag-and-Drop

Does this happen with drag&drop only, or also if you copy files from menu/keyboard shortcut?

Reply with quote

rye
Joined:
Posts:
1

it took me a few days to figure out why i kept getting those errors over and over
it wasn't until i noticed that files were appearing under winscp but were not appearing in windows explorer, it is because of the UAC virtualization

you need to run winscp as an administrator, every time you want to (actually) move or copy files to a directory not under your user directory
eg: program files (x86), windows

see:
<invalid hyperlink removed by admin>


if winscp was compiled with a UAC directive this bug would go away
also it would be able to store WinSCP.ini in C:\Program Files (x86)\WinSCP
instead of in C:\Users\<user name>\AppData\Local\VirtualStore\Program Files (x86)\WinSCP

the temporary fix of running as an administrator is not optimal since there could be power users with write privileges but they are not administrators

Reply with quote

Advertisement

wbkang
Guest

This is an invalid use case

Hi,

This really is an invalid use case. If you want to access system directories, you should run the program as administrator previledge.

It's UNIX-equivalent of saying "I can't write stuff in /usr/bin as a non-root user."

What are you trying to do? Any personal program data should be placed under %APPDATA% (typically /Users/username/AppData/Roaming).

Woongbin

Reply with quote

Advertisement

You can post new topics in this forum