[fpc-devel] ExtractFileDrive is broken under Linux

[Michael Van Canneyt]

On Wed, 21 May 2008, Graeme Geldenhuys wrote:

> Hi,
> 
> I reported this bug since FPC 2.0.2 as Mantis Bug #6491
>   http://bugs.freepascal.org/view.php?id=6491
> 
> The bug report contains a test application. Using FPC 2.0.2, 2 out of the 8
> tests failed. The result were consistent under Linux and Windows.  Now with
> FPC 2.2.1, all tests pass under Windows, but all tests _fail_ under Linux! Now
> it's even worse. :-(
> 
> The same with 'example34' mentioned in the FPC documentation. See the URL.
> 
> http://www.freepascal.org/docs-html/rtl/sysutils/extractfiledir.html
> 
> ---------- FPC 2.2.1 under Linux ---------------
> FileName      : c:\pp\bin\win32\ppc386.exe
> Has Name      : ppc386.exe
> Has Path      : c:\pp\bin\win32\
> Has Extension : .exe
> Has Directory : c:\pp\bin\win32
> Has Drive     :
> ------------------------------------------------
> 
> The last line 'Has Drive' should have reported 'c:' as the result.
> Irrespective of the platform I am running on, if I pass in a windows filename
> like 'c:\pp\bin\win32\ppc386.exe', I expect it to exact the drive letter
> correctly, given the parameter in question.
> 
> Or am I missing the point here??  It seems the behaviour of ExtractFileDrive()
> now looks at the platform it's running on, and just because Linux doesn't use
> drive letters, it immediately thinks the filename passed in doesn't contain a
> drive letter. Applying such Linux specific behaviour inside ExtractFileDrive()
> in not correct.

That depends entirely on your point of view. Linux knows no drive letters.
':' is a valid character in a filename, and therefor cannot act as a drive
separator character.

> What if I use a Linux application to process data from a remote Windows
> system?? I'm now getting inconsistent results!

Set AllowDriveSeparators to [':']. 

By default, linux indeed does not support drive letters, so support for
them is disabled in system routines. We made sure that people who want it
can still use it.

Be aware that
  ExpractFileName('c:\mypath\myfile:otherpart.ext')
will go wrong in this case.

in fact, the fix for this bug is the reason for the current behaviour.

And to be honest: parsing windows filenames on a linux system or 
vice versa, always goes wrong somewhere. So the routines only 
guarantee correct behaviour for the current platform.

Michael.