Ipswitch Forums / File Transfer / WS_FTP Server / "%File" contains mixture of physical and virtual path - a bug? / Latest Posts

RE: "%File" contains mixture of physical and virtual path - a bug?

dawidi — Mon, 28 Apr 2008 11:50:06 GMT

*bump*

I'd [i]really[/i] like to see this adressed ;)

RE: "%File" contains mixture of physical and virtual path - a bug?

dcrysler — Fri, 04 Apr 2008 11:18:32 GMT

I have a similar issue with file uploads, for example:

upload file: c:\FtpUsers\ftp\users\johndoe\upload\test.txt

Our customers have programs in place that login and instead of changing directories to the upload directory they simply perform a STOR command from the login directory and add the subfolder name onto the uploaded filename. ie STOR upload/test.txt. This method has always worked in the past, we just upgraded to version 6 of the server and now the %File argument is incorrect.

The file upload works and the file gets saved into the correct directory but the subfolder name is duplicated in the %File argument: C:\FtpUsers\ftp\users\johndoe\upload\upload\text.txt.

"%File" contains mixture of physical and virtual path - a bug?

dawidi — Thu, 03 Apr 2008 09:35:25 GMT

Hi,

I think I found a bug in WS_FTP Server 6, and I haven't found any mention of it so far, so I guess it hasn't been discovered yet.

When a file upload/download notification triggers on a file in a virtual folder, the parameter "%File" does not expand to the correct physical path of the file on the disk, but rather a mixture of the physical and virtual paths.
In our case we have paths like this:
E:\users\user1\
E:\users\user2\
and a virtual folder for user2, referring to the physical user1 folder.
Now when user2 downloads /user1/file.txt (from his view), %file in the download notification expands to
E:\users\user2\user1\file.txt
instead of
E:\users\user1\file.txt
and scripts called by the notification will report a "path not found" error.
I traced the log entries in our database, these errors started on the day we upgraded from WS_FTP Server 5 to 6, in October 2007.
We're currently testing a workaround that strips the extraneous part from the parameter, but that works only in our special case, and I think it should be fixed at the source.

Can someone reproduce the problem?