On Monday 26 June 2017 01:42 PM, Alistair Grant wrote:
1. Path's are canonicalised during initial creation, but are not when
extending the path, i.e. sending #/
E.g.
'/dev/shm/d1/d2/../t1.txt' asFileReference " File @ /dev/shm/d1/t1.txt"
'/dev/shm/d1/' asFileReference / 'd2/../t1.txt' " File @
/dev/shm/d1/d2/../t1.txt"
Automatic canonicalisation is problematic as the code doesn't handle
symbolic links in the path name:
('/dev/shm/d1/' asFileReference / 's3/../t2.txt') exists " true (correct
answer)"
'/dev/shm/d1/s3/../t2.txt' asFileReference exists " false (wrong answer)"
The meaning of 's3/..' is ambiguous when s3 is a symlink. Should 's3' be
resolved or not before #parent op is applied? Disambiguation depends on
context, so early canonicalization is a bug.
My own preference is to not to canonicalize at all and 's3/..' should be
left as {s3, ..}. See
http://man7.org/linux/man-pages/man7/path_resolution.7.html
2. In an attempt to be completely general, the argument to #/ is assumed
to be a single directory / file. This is incorrect as the path
delimiter is not allowed to be part of the file name. The result is
that path comparisons and operations such as #parent give unexpected
results.
Path class>>from:delimiter has a bug. It attempts to canonicalize
elements parsed from the String regardless of the context. If the code
is changed to:
pathClass withAll: (aDelimiterCharacter split: aString)
your test will pass.
I wonder why Path was subclassed from Object and not from
SequenceableCollection?
My PR modified FileSystem so that:
1. Canonicalisation is separated out as an operation that has to be
manually requested:
'/dev/shm/d1/d2/../t1.txt' asFileReference " File @ /dev/shm/d1/d2/../t1.txt"
'/dev/shm/d1/d2/../t1.txt' asFileReference canonicalize " File @
/dev/shm/d1/t1.txt"
I am ok with this.
2. The argument to #/ can be either a single file / directory name or a
path.
('/dev/shm/d1/' asFileReference / 'd2/d3/t3.txt') parent " File @
/dev/shm/d1/d2/d3"
ok with this too.
3. Adds unit tests to cover the changed behaviour.
...
Before I submit the patch, does anyone have any strong objections to the
changes as described above?
None from my side.
Regards .. Subbu
