dayamn.com

After persuading my client to use explicit SSL I ran into another very curious issue that I would like to share with you and maybe it will help you solve a similar problem.

When testing the solution I had to download the files inside a specific path of an FTP location. After downloading the files, I told my client that the solution was working fine but he replied telling me that the files were still in the path. I checked the path using my solution and the files weren’t there! All the files were downloaded to the destination folder and I could see them clearly.

Always blaming the user – as we engineers usually do – I asked my client to share his desktop so that I could see the folder he was looking at and make sure he was looking at the right path. What was my surprise when I saw the “same” folder I was looking at in my computer with a bunch of files pending to be downloaded.

After a couple of minutes scratching my head I realized that we were looking at two different folders using a similar path structure. But how was this possible? I hope I can make it clear enough for you.

Actually, my FTP solution was downloading the files from a relative path. As an example, I was told that after logging to the FTP location, I needed to go to the path “example1/download” to download the files. When I logged in using using my solution I didn’t realize that I was actually being redirected to a folder created for the credentials I was using when logging to the FTP location. As a result, I thought I was accessing the path

ftp://ftplocation.com/example1/download

when I was actually accessing the path

ftp://ftplocation.com/user1/example1/download

because of the automatic redirection to the user folder depending on the credentials used to access the FTP location.

I was having the problem because unfortunately, the FTP location happened to have both paths available – go figure! – and my client was looking at the absolute path – in the example above ftp://ftplocation.com/example1/download.

If you’re having the same problem you need to tell the FTPWebRequest instance that you will be using and absolute path. As the FTWebRequest class has its foundations in the HTTPWebRequest class you are not capable of controlling your FTP session, so you won’t be able to redirect to the root folder – in the example above ftp://ftplocation.com- and redirect to your specific path from there. Fortunately, the geniuses at Microsoft thought of a workaround to tell the FTPWebRequest class you will be using and absolute path instead of your default redirection or relative path.

The following code shows how to do that:

I know “%2f” is an escaped “/” but that’s how the class can tell if it will be using an absolute path instead of a relative one.

It’s simple right? Just add “%2f” before the specific path and you will make sure you are accessing the absolute path. Sometimes you will need  to use a relative path so it’s better if you make that option configurable – maybe a checkbox where you can choose between relative or absolute paths.

Ok, another workaround for the FTPWebRequest class that could save you some trouble.

Cheers!