Hi,

I'm trying to implement the new features that were added in Delphi 12 to TPath. I've made a naive implementation based upon available documentation. Some questions about how it is supposed to behave are missing though:
1. The docs state that an exception is raised if the given paths contain invalid characters. Does the vlaue of the ValidateParams have any influence on this?
2. If not: what does this ValidateParams parameter do then?
3. if multiple paths are absolute (e.g. the 2nd, 3rd and 6th path is absolute): what will be returned? (My guess: either the first absolute one it finds, or the last one.)

Could anybody with Delphi 12 test the TPath.Combine(const Paths: array of string; const ValidateParams: Boolean = True): string; function with the test program that is in the bugtracker
(https://gitlab.com/freepascal.org/fpc/source/-/issues/40513#note_1645757436)? Does it behave like the implementation I came up with? If a parameter is "invalid", but it is not used in the result (e.g. because there is a valid absolute path as the second or later argument in the array), will there be an exception?

Without (black box) testing it'll be impossible to implement these features.

Bart via fpc-pascal schrieb am Sa., 18.
Nov. 2023, 18:24:

1. The docs state that an exception is raised if the given paths contain invalid characters. Does the vlaue of the ValidateParams have any influence on this?

Also: does this depend on the operating system and/or file system? Cause Linux file systems have different invalid characters (usually only slash and NUL) than NTFS or FAT.

Regards,
Sven

Also: does this depend on the operating system and/or file system? Cause Linux file systems have different invalid characters (usually only slash and NUL) than NTFS or FAT.

Determining FileSystem at runtime, is that even possible? Adjusting the TPath.HasValidPathChars and TPath.GetInvalidPathChars functions for *nix maye be rather easy (there laready is non-windows code in that unit)

ValidateParams may even mean (ATM nobody seems to know) that the params must represent a valid path (either on it's own or after concatenation).

Attached program tests for invalid characters. if ValidateParams is False, no tests are done on input.

The output is in linux.txt and windows.txt

From what I can see all characters with ascii code < 32 are invalid.

For windows additionally, the > " < and | characters are invalid.

This is for paths only. I didn't test filename characters.

Michael.

You cannot test that as the path does not need to exist or does not even need to be complete. Consequently it's also not possible to determine the filesystem and hence not possible to test on that.

Note that there is also a 4 path elements version of the call. Seems to me you can simply repeatedly call the 2 path version from back to front.

If I need to do more tests, let me know.

Michael.

The output is in linux.txt and windows.txt

Thanks for testing.

It seems that it'll pick the last absolute path it finds, not the first one in the argument list.

It seems that DoTest('regular 1','a','\b','c'); will give '\b\c' That's confucing given that the Delphi docs suggest that if an absolute path is found (being not the firts argument), then this path will be the function result.
If that were to be true, I would expect the result to be '\b' in that case.

This raises the question what the result of
TPath.Combine(['a','\b',c'','\d','e']) would be (I would then expect either \b\c or \d\e)?

If ValidateParams is True, will it raise an error on invalid path characters in an argument that will not be used for the final result e.g. ['a','<|>','c:\foo']?

Given the purpose, I think it's perfectly logical since it starts from the back.

The purpose is to create an absolute path given some partial or complete paths. So you must start from the back.

I have a file myfile = 'c:\something\myfile.inc' that I must find in a path so I do

For P in SearchPath do
   begin
   F:=TPath.Combine(P,MyFile);
   if FileExists(F) then
     Exit(F)

The above should return myfile since that is an absolute filename.

\d\e

If ValidateParams is True, will it raise an error on invalid path characters in an argument that will not be used for the final result e.g. ['a','<|>','c:\foo']?

Yes. All arguments are checked.

Michael.

Thanks again for testing.
Where is EInOutArgumentException defined?
Probably it's defined as class(EInOutError)?
If so, what is the value of the ErrorCode property in this case?

Thanks again for testing.

What about ['c:','a','b']
Does it return c:a\b, or c:\a\b (on Windows), or IOW: does it take into account driveletters?
The first one IMO would be correct.

Put a new implementation in the bugreport.
Did not test the "wah is an illegal chatacter", IMO that should be a seperate issue.

Currently based upon these rules:

{
Concatenates the paths.
If one or more of the paths is absolute, it will use the right most absolute path as
base path and then concatenates the remaining paths to that.

  E.g. ['\a','b','\c','d'] will return '\c\d';
  If ValidateParam is True, and any of the paths contains an invalid

path character
an exception is raised.
No checks are done wether or not a given paths exists. E.g. ['\a','b','\c:'] will hapilly return the non-sensical path '\c:' }

My tests now give these results:

OK: ['']: Got: '', Expected: ''
OK: ['','']: Got: '', Expected: ''
OK: ['','','']: Got: '', Expected: ''
OK: ['a','b','c']: Got: 'a\b\c', Expected: 'a\b\c' OK: ['a','b','\c']: Got: '\c', Expected: '\c'
OK: ['a','\b','c']: Got: '\b\c', Expected: '\b\c' OK: ['\a','\b','c']: Got: '\b\c', Expected: '\b\c' OK: ['\a','\b','\c']: Got: '\c', Expected: '\c'
OK: ['\a','b','\c:']: Got: '\c:', Expected: '\c:' OK: ['a','','\b','c','\d'] --> EArgumentException, (as expected) FAIL: ['c:','a','b']: Got: 'c:\a\b', Expected: '?' <== don't know what the expected value should be here

NOT ValidateParams
OK: ['']: Got: '', Expected: ''
OK: ['','']: Got: '', Expected: ''
OK: ['','','']: Got: '', Expected: ''
OK: ['a','b','c']: Got: 'a\b\c', Expected: 'a\b\c' OK: ['a','b','\c']: Got: '\c', Expected: '\c'
OK: ['a','\b','c']: Got: '\b\c', Expected: '\b\c' OK: ['\a','\b','c']: Got: '\b\c', Expected: '\b\c' OK: ['\a','\b','\c']: Got: '\c', Expected: '\c'
OK: ['\a','b','\c:']: Got: '\c:', Expected: '\c:' OK: ['a','','\b','c','\d']: Got: '\d', Expected: '\d'

No. EArgumentException.

If so, what is the value of the ErrorCode property in this case?

There is no errorcode, since there is no IO. It's purely a string operation.

Michael.

It returns c:a\b

Michael.