Indy Homepage

Indy.Sockets (VCL) 

Web Designer Wanted!

   Articles   |  Download   |   F.A.Q.   |   Support   |   Teams   
    Indy Project  »  Indy (VCL)  »  Indy Core Blogs  »  J. Peter Mugaas's Indy Blog
 

About

Bug List

Indy Core
Team Blogs

Knowledge
Base

License 

Website problems?
Contact webmaster.
 

Website


Our builds are

Version control by

Docs made with

 

Path Processing in the Indy FTP Server

Path Processing in the Indy FTP Server

This describes some recent improvements in how pathes are processed by the FTP Server.

Recemtly, I completed a major improvement in the FTP server that someone else had started (It might have been me, I don't remember).  Well, anyway, the big change is that pathes are passed from the server to your program in an absolute manner.  What I mean by absolute is that if the current directory is "pub" and you retreive "sample.exe", the parameter passed to the OnRetrieveFile was "sample.ext".  The new behavior is that "/pub/sample.exe" is passed to the OnRetrieveFile event.

This improevements means that you no longer have to deal with the relationship of a file specification with the current directory.  That has often been very tricky because some FTP clients pass the complete file path while others will pass something relative such as "pub/sample.exe" or possibly "./pub/sample.exe" (both are the same thing, BTW, but it would not always be obvious).  On Windows systems, this is even worse because the "\" is treated as if it was a "/" and some clients may pass the "\" symbol to a Windows servers.   Then you also have symbols like ".." or "../" that make path processing even more difficult because those mean, move up a level.   Writing code for all of this tends to get very messy.  By only passing absolute pathes to the OnRetreiveFile event, you much cleaner code such as this:

function TForm1.ReplaceChars(APath:String):String;
var
 s:string;
begin
  s := StringReplace(APath, '/', '\', [rfReplaceAll]);
  s := StringReplace(s, '\\', '\', [rfReplaceAll]);
  Result := s;
end;  
  
procedure TForm1.IdFTPServer1RetrieveFile(ASender: TIdFTPServerContext;
  const AFileName: string; var VStream: TStream);
begin
  VStream := TFileStream.Create(ReplaceChars(AppDir+AFilename),fmOpenRead);
end;

For controlling how pathes are processed in the FTP server, we have a published "PathProcessing" property.  This property can be one of these values:

  1. ftppDOS - process the path like most Windows servers. The "\" is treated as if it was a "/". Filenames with a "\" are not permitted.
  2. ftppUnix - process the path like most Unix servers. The "\" is treated as a valid filename character.
  3. ftpOSDependent - On Windows and DotNET, this works exactly like ftppDOS and in Linux, it is treated exactly like "ftppUnix". This is for cross-platform work
  4. ftppCustom - use the OnCustomPathProcess event to do all of your own path processing in your program.  You are responsible for processing all path symbols with this event.  This is for situations where your application needs to do something unusual such as emulate a VMS box.   The event is definated as:
    TOnCustomPathProcess = procedure(ASender: TIdFTPServerContext; var VPath : String) of object;
    where VPath is what the server received and you set that to the path as your program needs to process it.

I know that is not a populat thing to blog about. Unfortunately, I feel that this is critical in many FTP servers.  Improper path handling can permit someone to have to have access to something that they should not have access to.  I was horified that I could even get into my Windows system due a bug in some code I was writing.  Let that a kind warning to you.

 << Previous Entry     Next Entry >>

Corporate Sponsors
[Image] [Image]

 

Copyright © 1993 - 2008
Chad Z. Hower (Kudzu)
and the Indy Pit Crew.

Using Indy in your software?
  
Click on the image for more
Indy logos and graphics.