根据你提供的命令行参数和日志信息，我整理了几个最可能的原因，按优先级排序：

1. 目标路径未加反斜杠，导致文件被重命名为文件夹名称 #

这是WinSCP命令行最容易踩的坑！你的get命令是：

get /Inbox/* C:\TEST\Automation\NewFolder

如果C:\TEST\Automation\NewFolder这个文件夹不存在，WinSCP不会自动创建它，反而会把下载的文件直接保存为NewFolder这个文件（而不是文件夹）。日志里的传输记录也能佐证这一点：

. 2018-05-23 12:07:50.937 Transfer done: '/Inbox/FILENAME.txt' => 'C:\Test\Automation\NewFolder' [163487]

注意目标路径后面没有文件名，直接是NewFolder——这说明WinSCP把FILENAME.txt下载后重命名成了NewFolder文件，而不是放到NewFolder文件夹里。你现在去C:\TEST\Automation目录下看看，应该能找到一个叫NewFolder的文件，打开它就是你要的FILENAME.txt内容。

解决方法：给目标路径加上末尾的反斜杠，确保WinSCP识别为文件夹：

get /Inbox/* C:\TEST\Automation\NewFolder\

或者先手动创建NewFolder文件夹，再执行get命令。

2. 路径大小写差异导致找错了位置 #

日志里显示的目标路径是C:\Test\Automation\NewFolder（首字母Test是小写t），但你指定的命令行路径是C:\TEST\Automation\NewFolder（大写TEST）。虽然Windows文件系统默认大小写不敏感，但在某些特殊场景下（比如启用了NTFS大小写敏感属性，或者通过特定API访问），可能会出现“看起来同名但实际是不同路径”的情况。

建议你直接复制日志里的路径C:\Test\Automation\NewFolder到资源管理器地址栏，看看里面是否有下载的文件。

3. 权限问题导致文件被Windows重定向 #

如果运行WinSCP的账户（比如调度任务使用的系统账户或其他用户）没有写入C:\TEST\Automation\NewFolder的权限，Windows会自动把文件重定向到虚拟存储路径，比如：
C:\Users\<你的用户名>\AppData\Local\VirtualStore\TEST\Automation\NewFolder

你可以去这个路径下检查是否有下载的文件。解决方法是给运行WinSCP的账户分配C:\TEST\Automation\NewFolder的读写权限。

4. 调度任务的运行上下文问题 #

如果你是通过Windows任务计划程序执行这个命令，需要确认：

• 任务的“运行用户”是否有访问目标文件夹的权限（比如不要用系统账户，改用有足够权限的普通用户）；
• 不要勾选“不管用户是否登录都运行”，除非你确定系统账户能访问该路径；
• 检查任务的“起始于”设置，确保没有相对路径干扰（不过你用的是绝对路径，这个可能性较低）。

内容的提问来源于stack exchange，提问作者James West