Change Directory.list to use the input path, and not resolve it to a full path.

Change Directory.list to use the input path, and not resolve it to a full path.
All paths reported by Directory.list are now extensions of the input path.

The Windows platform equivalent change will be committed in a separate CL.

BUG=

Committed: https://code.google.com/p/dart/source/detail?r=18739

[Bill Hesse, 2013-02-08 16:21:53]

Not for committing - just a preview of the final change.  Seems to be bug-free
and have the correct behavior.

No errors on pub tests, one (expected) error on standalone (the test is wrong).

[Bob Nystrom, 2013-02-11 18:49:17]

On 2013/02/08 16:21:53, Bill Hesse wrote:
> Not for committing - just a preview of the final change.  Seems to be bug-free
> and have the correct behavior.
> 
> No errors on pub tests, one (expected) error on standalone (the test is
wrong).

Justin just pointed out to me that pub's current workaround for this fails when
the basename varies between the symlink and the destination file, so we'll be
very happy to have a solid implementation of this in dart:io so we don't have to
hack around it.

[Bill Hesse, 2013-02-13 19:09:20]

Works, no pub failures, and cleaned up nicely.  Making PathBuffer an automatic
variable with destructor cleaned up early returns nicely.

[Bill Hesse, 2013-02-13 19:28:51]

https://codereview.chromium.org/12217086/diff/4001/runtime/bin/directory_linu...
File runtime/bin/directory_linux.cc (right):

https://codereview.chromium.org/12217086/diff/4001/runtime/bin/directory_linu...
runtime/bin/directory_linux.cc:77: }
I just realized I should remove Add(path separator) from here, DeleteDirectory,
List, and Delete, and add it to the beginning of ListRecursively and
DeleteRecursively.

[Anders Johnsen, 2013-02-14 10:32:00]

While we are in the area, would it make sense to just return only the path
element, just like 'ls' and 'dir'? Also, how will this be translated into the
new API? 

Maybe we should wait for Mads' and Soeren's input on Monday.

[Bill Hesse, 2013-02-14 10:41:28]

On 2013/02/14 10:32:00, Anders Johnsen wrote:
> While we are in the area, would it make sense to just return only the path
> element, just like 'ls' and 'dir'? Also, how will this be translated into the
> new API? 
> 
> Maybe we should wait for Mads' and Soeren's input on Monday.

I am open to the idea of just returning the path relative to the directory being
listed, but that is a big breaking change, that has many stakeholders.

This step should be taken independently of whether we make that major change -
pub users, and probably others, want the returned paths to point to locations
inside the original directory (containing the listed directory path as a
prefix), rather than absolute paths to new locations, with no connection to the
original directory.

Showing the path to the link target, rather than the path through the link, is
also inconsistent between Windows and the other platforms - windows does not
resolve the link this way when fullPath is called.

There should be no problem implementing this with the new API - the returned
paths will be File and Directory objects, which are both FileSystemEntity
objects.

[Bob Nystrom, 2013-02-14 14:59:16]

On 2013/02/14 10:41:28, Bill Hesse wrote:
> On 2013/02/14 10:32:00, Anders Johnsen wrote:
> > While we are in the area, would it make sense to just return only the path
> > element, just like 'ls' and 'dir'? Also, how will this be translated into
the
> > new API? 

I think that would place a usability tax on users since in the majority of cases
they would then have to prepend the original directory path to get a usable
path.

> I am open to the idea of just returning the path relative to the directory
being
> listed, but that is a big breaking change, that has many stakeholders.

There is a third option which I think this should do, which is return a path
whose prefix is the directory path. In other words, if I call new
Directory("foo").list(), options are:

1. Relative to foo: "bar/baz"
2. Prefixed with foo: "foo/bar/baz"
3. Absolute: "/path/to/foo/bar/baz"

I think it currently does 3? Either way, I believe 2 is the most useful.

> This step should be taken independently of whether we make that major change -
> pub users, and probably others, want the returned paths to point to locations
> inside the original directory (containing the listed directory path as a
> prefix), rather than absolute paths to new locations, with no connection to
the
> original directory.

Yes, this is absolutely necessary and not something we can workaround. (Our
current workaround for this is a hack and fails in some cases). Resolving
symlinks is something the user should specifically opt into because once it's
done it can't be undone.

> Showing the path to the link target, rather than the path through the link, is
> also inconsistent between Windows and the other platforms - windows does not
> resolve the link this way when fullPath is called.

We definitely want consistency across OSes.

- bob

[Bill Hesse, 2013-02-14 15:54:34]

This changelist implements Bob's choice number 2: All paths start with the path
of the input directory, and do not make this path absolute.

So the directory structure
/path/to/foo/file1
            /dir1/file2
            /link1 -> ../bar
        /bar/dir3/file3
                 /dir4
would make Directory("foo").list(recursive: true) return
foo/file1
foo/dir1
foo/dir1/file2
foo/link1
foo/link1/dir3
foo/link1/dir3/file3
foo/link1/dir3/dir4

if the current directory is /path/to.

[Mads Ager (google), 2013-02-19 07:14:59]

lgtm

[Søren Gjesse, 2013-02-19 08:22:44]

I don't think we should prefix with the directory being listed and I think that
Bob's choice no. 1 is better. I do see that in many cases you would want to
prefix with the directory being listed, but the content of a given directory
should be the same no matter how it is accessed, e.g. with the following
structure

/path/to/foo/file1
            /dir1/file2

and cwd in /path/to

Directory("foo").list()
Directory("/path/to/foo").list()
Directory("../to/foo").list()

should all give

  file1
  dir1

and if recursive

  file1
  dir1
  dir1/file2

The content of a directory is the same no matter what path you take. If
prefixing is commonly used we can consider an additional optional argument.
Likewise making absolute paths can be an option if this is a common use case.

[Mads Ager (google), 2013-02-19 08:38:35]

I see Søren's point that no matter how you get to a directory, the contents is
the same and should be listed the same no matter how you point to it.

[Bill Hesse, 2013-02-20 09:27:16]

Committed patchset #3 manually as r18739 (presubmit successful).

[Søren Gjesse, 2013-02-20 09:36:23]

LGTM

As discussed offline the current solution with prefixing the names from list
will not break current code and also play more nicely with the changes to
Directory.list in the IO v2 branch.