Inconsistency in FileTransferProgressEventArgs Filename property

Using 5.9.4:

On upload, when files are transferred and the FileTransferProgress event is fired, the filename property contains the full path of the local file being transferred (as it should).

On download, however, it only returns the filename only. This makes it impossible to tell where the file is in the server hierarchy.

So let's say I'm downloading: "/myfolder" and there's a subfolder & file there "/mysubfolder1/myfile.txt". When transferring "/mysubfolder1/myfile.txt", it will only return "myfile.txt". So how I am I able to know where exactly the file is? I have no way to know that it's in /mysubfolder1. In this example, if you specify "/myfolder" to download, I would expect the filename property to contain "/myfolder/mysubfolder1/myfile.txt" when transferring that file.

While on the subject of this filename property, you really need to have both the source and target paths passed in this event. You really should get rid of Filename and have SourcePath and DestinationPath properties. I mean an event that gets fired when a file is being transferred SHOULD contain the actual full path of the file being transferred and where that file is going.

Here's the issue Martin:

In my app, there's a cancel button to cancel an active file transfer. The only way I know of to actively cancel a transfer (without waiting for it to finish) is to stick a piece of code in my app when the FileTransferProgress event is fired to check for cancel and if so, to call Session.Abort to force abort. The problem with this is that WinSCP may leave behind .filepart files (this is another issue - WinSCP should first delete the .filepart file before aborting in this instance IMHO). Since it might leave this behind, I make note of the file being transferred via the Filename property and then log back in to delete the .filepart file if it exists with Session.RemoveFiles. When uploading, the filename property contains the local file path. Since there is no property in that event that contains the path to the file on the server (it should!), I then have to figure that out with a call to Session.TranslateLocalPathToRemote first to try to get what was the destination file path on the server. Then I add ".filepart" to it and log in and call RemoveFiles. It does work for uploading. But when downloading, because the filename property does not contain the full server path to the file but only the filename itself, I don't know where the file is to pass to Session.TranslateRemotePathToLocal in order to get the local file path (so I can delete the ".filepart" file in the local path).

Please attach a full session and debug log files showing the problem (using the latest version of WinSCP).

martin wrote:

Please attach a full session and debug log files showing the problem (using the latest version of WinSCP).

I don't really know what log files do for you here - the problem is described fulled above, but I've attached them anyway. I aborted the download in the FileTransferProgress event on the file "/shares/1-TV/sdbstatus/giblet/SupermarketScrambleDemo10.exe"

You will note in the logs that it shows only the filename "SupermarketScrambleDemo10.exe" in that event in this case and that does not show the full path "/shares/1-TV/sdbstatus/giblet/SupermarketScrambleDemo10.exe" for the filename like local paths do when uploading.

But again, per my original post, there are also other issues I believe you need to be considering besides just fixing this one problem because really that event needs to have both the source and target paths in it and it does not have that. And the whole reason I needed to use this is because upon abort, it's leaving behind the .filepart file which IMO when there's an abort, the .filepart file should be removed or there should at least be an option for that. A forced abort is different then a session timeout or network prob. When there's a forced abort, the user is saying "I don't want to upload/download this - I've changed my mind" so any .filepart files needs to be deleted. As it is now I have to jury-rig a solution to try to get the path on the server to the file where the abort occurred so I can log back in to delete the .filepart file. But that won't always work on downloads because of the Filename bug as per the original post.

There's FileTransferProgressEventArgs.Directory:
https://winscp.net/eng/docs/library_filetransferprogresseventargs#directory

And it seems to be filled correctly, according to the log you have provided:

[2017-05-09 01:47:43.444Z] [0005] File Name [SupermarketScrambleDemo10.exe] - Directory [c:\temp\] - Overall Progress [45] - File Progress [0] - CPS [19952999]

that event needs to have both the source and target paths in it and it does not have that.

OK, will consider that.

And the whole reason I needed to use this is because upon abort, it's leaving behind the .filepart file which IMO when there's an abort, the .filepart file should be removed or there should at least be an option for that.

It's consistent with a GUI behavior. It's there to allow transfer resume. I didn't have any complains about that so far.

martin wrote:

There's FileTransferProgressEventArgs.Directory:
https://winscp.net/eng/docs/library_filetransferprogresseventargs#directory

And it seems to be filled correctly, according to the log you have provided:

[2017-05-09 01:47:43.444Z] [0005] File Name [SupermarketScrambleDemo10.exe] - Directory [c:\temp\] - Overall Progress [45] - File Progress [0] - CPS [19952999]

No that is not correct. First, it is true that I missed the Directory property (don't know how I missed that!) but according to the documentation that property is supposed to contain the source directory. "c:\temp" is NOT the source directory. Actually it's not even the target directory! This is a download operation from the server and source directory would be "/shares/1-TV/sdbstatus/giblet/" and the source filename would be "SupermarketScrambleDemo10.exe" and the target directory is c:\temp\ftpdowntest\giblet" and target filename would be "SupermarketScrambleDemo10.exe"

I can't do ANYTHING with a directory property that tells me "c:\temp" and a filename "SupermarketScrambleDemo10.exe". I still have no way to know from those what the actual source directory was where that file was located, nor do I know from that what folder the file will be placed in. Basically it's completely useless.

Further, as mentioned, on upload (local -> server), the Filename property does contain the full source path of the file being transferred, unlike on download.

As for the .filepart files consider this:

I use WinSCP to transfer sometimes multi-gigabyte files in a backup/archive type situation. If a user cancels the operation mid-way through, it leaves behind .filepart files that are potentially large. The source file may (and likely will be in my case) change before a run is attempted again. One would assume that WinSCP is smart enough to know that if the source file changed to start over and delete the .filepart file and not try resuming (I didn't test this but I certainly HOPE WinSCP does that - clarification here would be helpful). But even assuming WinSCP is smart enough to known not to resume when the source changed, it still leaves a potentially very large .filepart file until the next run when it figures that out. And if the user uninstalls my program or doesn't want to use it anymore, it left behind a very large .filepart file on their server leading to unhappy users (people mad at me).

I understand the resume operation and can see why sometimes that might be helpful (even on abort I suppose tho I still question whether it should be used at all on abort), but what would be really helpful is if there was an option controlling that. There are times (i.e. in my case!) where it would not be desirable to ever leave behind .filepart files.

Just wanted to make sure you saw my last comment Martin. :) Thanks again! :) -Chris

This issue has been added to the tracker:
https://winscp.net/tracker/1531

WinSCP .NET assembly will now also allow you to cleanly cancel the transfer, without aborting the session:
https://winscp.net/tracker/1532

I'm sending you an email with a development version of WinSCP to the address you have used to register on this forum.

martin wrote:

I'm sending you an email with a development version of WinSCP to the address you have used to register on this forum.

Thank you so much Martin! :) I received and I will plan to test it and get back to you within the next day or two.

Chris

martin wrote:

WinSCP .NET assembly will now also allow you to cleanly cancel the transfer, without aborting the session:
https://winscp.net/tracker/1532

I tested the development version. The Filename property does indeed now contain the full path when it is a server path just as it always did for local paths. I still think the Directory property is messed up, but I don't use actually use that property except for testing. It still shows "c:\temp" in my example above, which is not correct as that is neither the source nor target directory.

I also tested the Cancel property. It does indeed Cancel but it still leaves behind the .filepart file, so I'm really not clear what my benefit is to using it over Abort except that it doesn't actually close the session/disconnect which presumably allows me to then manually delete the filepart file in the same session without having to log back in (I still have to determine the correct path of the filepart file using the TranslateLocalPathToRemote/TranslateRemotePathToLocal functions). I think on at least one of those 2 (cancel or abort - and I lean towards abort) that winscp should delete the filepart file itself.

But I'm happy since it is at least possible now to get the filepart file deleted in all circumstances since you fixed the filename property.

Thanks Martin. :)

Also just an additional note:

It is fairly clear to me now that the original intent was to have the full source folder in the Directory property and only the filename in the Filename property (or else why would you have had two properties? If you intended for full path you would not likely have called the property Filename but rather SourcePath or something)

The Directory property as described above does not work correctly. And while you changed the Filename property to now contain the full path so that there's at least always useful data now, I am wondering if actually the best approach would be to fix both to work as they were originally intended?

In other words, the bug may not have been as I described in my first post (where I didn't even realize there was a Directory property). The bug actually may not have been that Filename did NOT contain the full path on download, but that it DID contain the full path on upload. The bug was probably that Filename contained the full path when referencing local files. Combined with the bug that the Directory property does not show the correct directory. If the Directory property correctly shows only the full directory on both local and server and the Filename property contains only the filename on both local and server, then that would also solve this and probably be more in line with what you originally intended. Tho I also still personally think you should just scrap both and make a SourcePath and TargetPath property where the SourcePath contains the full source path (just like Filename is NOW working after your change) and the TargetPath contains the full target path.

In any event, I don't really care now cause all I really needed was to know the full target path and with the full source path in Filename combined with the Translate functions, I can get the target path, but I just am posting this for your consideration.