I'm using WinSCP's .NET assembly from PowerShell to export data and upload a CSV file over SFTP. The script completes and prints a success message, but the file is not actually created or updated on the server. When the target file already exists, its timestamp and size remain unchanged. Uploading the same file manually with the same account works, although that account appears unable to delete, move, or rename files.
Here is the relevant upload code:
```powershell
$transferOptions = New-Object WinSCP.TransferOptions
$transferOptions.TransferMode = [WinSCP.TransferMode]::Binary
$transferOptions.ResumeSupport.State = [WinSCP.TransferResumeSupportState]::Off
$transferResult = $session.PutFiles("$PSScriptRootdata.csv", ".", $False, $transferOptions)
$transferResult.Check()
foreach ($transfer in $transferResult.Transfers) {
Write-Host "Upload of $($transfer.FileName) succeeded"
}
```
Changing the remote path to `/*` appears to make the upload work:
```powershell
$transferResult = $session.PutFiles("$PSScriptRootdata.csv", "/*", $False, $transferOptions)
```
I understand that accepting any SSH host key and storing a plaintext password are unsafe for production; those are separate issues. What is the difference between using `.` and `/*` as the second argument to `PutFiles()`?
3 Answers
`Check()` only throws if WinSCP reports a failed transfer. Since the transfer result contains a successful entry, the upload operation itself was accepted for the path supplied. It is still worth logging the resolved local path, the remote path, and each transfer’s `Destination` property so you can verify exactly where WinSCP wrote the file. Also add a `catch` block so connection and transfer errors are not hidden by the `finally` block disposing the session.
A practical way to troubleshoot this is to open the same connection in the WinSCP client, navigate to the directory where manual uploads succeed, and use that exact remote path in `PutFiles()`. WinSCP can also generate example PowerShell or command-line code from a saved connection, which helps reveal path and authentication differences. Built-in OpenSSH or another SFTP module can work too, but changing tools will not fix an incorrect destination path.
The problem is the remote path passed to `PutFiles()`, not necessarily the SFTP permissions. The second argument is the complete destination path, and it can include an operation mask when uploading files. `/*` means the root directory of the SFTP session, with `*` preserving the local filename. Depending on the server and the account’s SFTP root, `.` may not resolve to the directory you expect. Try using the exact remote directory and filename, or a remote path ending in `/` when you want to keep the local filename.
The root shown to an SFTP account can also be a restricted or chrooted root, so it may not match the server’s normal filesystem root. The account’s manual upload location and the path used by the script need to be compared from within the same SFTP session.