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. What if I use a Linux application to process data from a remote Windows system?? I'm now getting inconsistent results!

Regards,
- Graeme -

_______________________________________________________ fpGUI - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

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.

Michael Van Canneyt wrote

That depends entirely on your point of view.

I like to be difficult! :-)

Linux knows no drive letters. ':' is a valid character in a filename, and therefor cannot act as a drive separator character.

Oh! I never knew ':' is a valid filename char. Whoever uses that must be shot, no questions asked! ;-) With my new found knowledge, I see your point.

> What if I use a Linux application to process data from a remote Windows > system?? I'm now getting inconsistent results! Set AllowDriveSeparators to [':'].

Brilliant, that should do the trick. :)

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

Nice catch, I better make a note of that as well.

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.

What about WebServices or CGI apps running on a Linux server? You could very well upload a file containing data generated on a Windows system, but the WebService running on a Linux system will process that data.

Thanks for explaining the behaviour change Michael. I'll update my applications accordingly.

Regards,
- Graeme -

_______________________________________________________ fpGUI - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

Sure, but in that case you'll have to do custom processing anyway.

Thanks for explaining the behaviour change Michael. I'll update my applications accordingly.

The constants are documented, BTW. Not yet on the web, but definitely in subversion.

Michael.

Michael Van Canneyt wrote

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.

hehehe... To really screw with a Windows user, I tried the following and it worked!

touch 'c:\myfile.txt'

Under linux it actually create the file called 'c:\myfile.txt'

:/tmp$ ls -l
drwxr-xr-x 3 graemeg graemeg 4096 2008-05-21 11:43 app -rw-r--r-- 1 graemeg graemeg 0 2008-05-21 13:14 c:\myfile.txt -rw-r--r-- 1 graemeg graemeg 0 2008-05-21 13:12 c:myfile.txt -rw------- 1 graemeg graemeg 607 2008-05-21 11:48 code-1.pp -rw------- 1 graemeg graemeg 607 2008-05-21 11:48 code.pp

That's nuts! :-)

Regards,
- Graeme -

_______________________________________________________ fpGUI - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

Why? Because it does what you ask? :-)

Micha

Yes, but it gets a stream. No need for a full path. name.ext at best.

system data. A listing of directories and files with CRC checksum (our actual example), log entries etc...

Regards,
- Graeme -

_______________________________________________________ fpGUI - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

on unix you can even create weirder filenames:

~]$ ls -lbQ
total 1348
-rw-rw-r-- 1 marc marc 0 2008-05-21 22:37 " " -rw-rw-r-- 1 marc marc 0 2008-05-21 22:31 "\n" drwxr-xr-x 2 marc marc 4096 2008-03-18 00:11 "bin" ...

in the early days accessing ftp warez sites having dirs starting with #0 was fun :)

Marc

Well, don't do the wrong thing when deleting this nasty little file:

[...]
-rw-r--r-- 1 vinzent vinzent 0 2008-05-22 17:44 " -rf *" [...]

Vinzent.