View Issue Details

IDProjectCategoryView StatusLast Update
0037188LazarusLazUtilspublic2020-06-28 16:14
ReporterJuha Manninen Assigned ToBart Broersma  
PrioritynormalSeverityminorReproducibilityalways
Status assignedResolutionopen 
Product Version2.1 (SVN) 
Summary0037188: Unit test for function TrimFileName fails
DescriptionRunning cmd line program "runtests" with parameter "--suite=TTestLazFileUtils" gives output:

<Test Name="TestTrimFileName" Result="Failed" ElapsedTime="00:00:00.000">
  <Message>TTestLazFileUtils.TestTrimFileName: "a/." expected: <a/> but was: <a></Message>
  <ExceptionClass>EAssertionFailedError</ExceptionClass>
  <ExceptionMessage>"a/." expected: <a/> but was: <a></ExceptionMessage>
</Test>

The test is in procedure TTestLazFileUtils.TestTrimFileName in line 136 of unit TestLazFileUtils.
  DoTest('a/.','a/');
So the test expected 'a/' but got a plain 'a'.
Steps To ReproduceOpen project test/runtests.lpi and build it.
Then run it from console as "runtests --suite=TTestLazFileUtils".
TagsNo tags attached.
Fixed in Revision
LazTarget-
Widgetset
Attached Files

Activities

Bart Broersma

2020-06-14 22:26

developer   ~0123438

The comments for TrimFilename state:
//Trim leading and trailing spaces
//then call ResolveDots to trim double path delims and expand special dirs like .. and .

This behaviour is explicitely documented in the sourcecode of ResolveDots:

        if (DestPos>2) and (Result[DestPos-1]=PathDelim)
        {$ifdef windows}
        and not IsDriveDelim(Result,DestPos-2)
        {$endif}
        then begin
          // foo/. -> foo
          // C:foo\. -> C:foo
          // C:\. -> C:\
          dec(DestPos);
        end;

So IMO it is expected that 'a/.' becomes 'a'

So the test seems wrong.

Juha Manninen

2020-06-15 12:21

developer   ~0123443

Bart, please use your judgement to fix the test case. Assigning to you.
Please also look at the other tests in procedure TTestLazFileUtils.TestTrimFileName, too. Some results also end with '/'. Is it consistent?

Bart Broersma

2020-06-15 14:45

developer   ~0123444

Where can I find the test in question?

Bart Broersma

2020-06-17 22:21

developer   ~0123462

OK, it looks like ResolveDots is not consistent:
foo/ -> foo
foo/. -> foo

While, as long as filenames are concerned (well these will actually be directories) foo/, foo/. and foo all point to the same folder, it is a bit confusing.

Changing that behaviour is, I think, unlikely to break existing programs.
The ResolveDots function (of which I think I wrote the first version) has however ecome rather complicated to follow.

Removing the piece of code that changes foo/. to foo, seems to fix this, but I can't really oversee what side-effects it may have.

Issue History

Date Modified Username Field Change
2020-06-09 13:58 Juha Manninen New Issue
2020-06-09 14:02 Juha Manninen Description Updated View Revisions
2020-06-09 14:02 Juha Manninen LazTarget => -
2020-06-14 22:26 Bart Broersma Note Added: 0123438
2020-06-15 12:21 Juha Manninen Note Added: 0123443
2020-06-15 12:21 Juha Manninen Assigned To => Bart Broersma
2020-06-15 12:21 Juha Manninen Status new => assigned
2020-06-15 14:45 Bart Broersma Note Added: 0123444
2020-06-17 22:21 Bart Broersma Note Added: 0123462