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.

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)


Topic review


Sorry for the spam, I'll just keep answering myself :-)

The following code demonstrates my mistake – if you feed Get-ChildItem a null it returns the current directory; I thought it would return null itself.
Get-ChildItem $null

(returns the current directory)

CONCLUSION: not a bug, just a PowerShell coding mistake.

Hmm, so I'm looking at my new script and see an important detail. Immediately after I call Session.Putfiles I do the following if-then check – and it works successfully, i.e., the Transfers.FileName method appears to correctly return a null/false:
If ( !($TransferResult.Transfers.FileName) ) { Write-Host "no source files found"}

The issue occurs when I use that same method with Get-ChildItem. So maybe I'm just misusing the results? Either way, it suggests that my workaround is to do the same if-then before starting my archive function.

.NET 'Transfers.Filename' returns wrong list

I have a known-good PowerShell script which uses the WinSCP .NET component. I added a new function to move successfully uploaded files to an archive folder, and it blew-up on me. I think I have identified the problem, related to the NewerOnly parameter. I have listed the pertinent commands below; I skipped all the other stuff but I can post more detail if you're unable to recreate the problem.
$TransferResult = $Session.PutFiles("$($Transfer[0])", "$($Transfer[1])", $DeleteAfterTransfer, $transferOptions)
$FilesToArchive = Get-ChildItem $TransferResult.Transfers.FileName

The problem occurs when there are files in the local source dir but they are skipped because they already exist in the remote target (the NewerOnly Session option). In this situation I am expecting the .Transfers.Filename method to return a null – but instead it returned the contents of the current script directory. So my testing resulted in the upload script etc all being moved into the upload-file archive; oops

Can you verify if this is a bug in the Transfers and/or Filename method?
Is there a better way for me to check which files were, in fact, transferred?

Thank you for your assistance.