Provide path manipulation support in dart:io

[munificent]

Given a File object, it's useful to get its containing Directory. Ideally:

  var file = new File(...);   Directory dir = file.directory;

Path manipulation functions (dirname, basename, etc.) in general would be useful.

[madsager]

Removed Type-Defect label. Added Type-Enhancement, Accepted labels.

[madsager]

cc @sgjesse. Set owner to @whesse.

[madsager]

Stealing this back. I'll add File.directory() and File.directorySync() methods to the File interface.

---

cc @whesse. Set owner to @madsager. Added Started label.

[madsager]

Access to the containing directory for a file is now available. I agree that we need more path manipulation functionality. We were considering whether or not it would make sense to perform those manipulations using URIs. Extend the File interface with the ability to get a file URI from a file and have a constructor that takes a File URI. The extend the URI library with nice manipulation functionality. This is still a bit in the air but it is definitely on our radar.

---

Added Fixed label.

[munificent]

Why are there sync and async versions, and why aren't they getters? The directory path for a file is a simple easy-to-calculate property of the file isn't it?

[madsager]

It requires native calls and inspection of the file system. If your file system is slow NFS drive or something similar that could block the main thread for a while. I'm actually still in favor of not having any sync methods in the API at all (but we have the sync methods because I realize that for parts of your code not having them can be pretty hostile to users).

[munificent]

I don't understand. Isn't this just a string operation on the path? If not, why not?

[madsager]

Because we use the system to deal with '/' and '\' differences and the like. It probably could be implemented as a pure string operation but there are many cases to consider that the system handles for you already.

[munificent]

So can I use this to manipulate fictitious paths to files that don't exist?

[madsager]

At this point this only works for files that exist. Is that too restrictive?

[munificent]

Yes, it is. I think there's two broad classes of functionality I want:

1. An API for making it pleasant to work with file paths. Things like "get the extension", "get the basename", "get the parent directory", "join a series of paths", and possibly even canonicalization.
2. An API for accessing the file system: open a file at a path, traverse the contents of a directory, see if a file exists.

The former should explicitly not require those paths to exist or even be meaningful: programs often manipulate paths (or URLs) that don't correspond to the file system the program is running on. The latter, obviously, should. :)

[madsager]

Bob, let me keep this bug open and change it to a bug path manipulation.

What do you think of the idea I alluded to above that path manipulation (without access to the file system) could be done as part of a URI library with lots of functionality for File URIs?

---

Added Accepted label.

[madsager]

Changed the title to: "Provide path manipulation support in dart:io".

[munificent]

I think that might work? I'd have to see the actual API to get a feel for how it would go in practice. It seems like there's stuff that wouldn't make sense for URIs that we would still want, though, right? Things like "extension" aren't something I would expect in a URI library but I would in a path one.

Even though there is likely to be overlap between the two, it may be more usable to have two separate libraries. My hunch is that users are mentally in the mode of either "I'm working with file paths" or "I'm working with URIs" and would expect to find a library for each. Having to know to use the URI library when they're thinking "path" might be confusing.

[madsager]

Set owner to @whesse.

[madsager]

Added this to the M1 milestone.

[madsager]

dart:io has simple path support. Let's close this bug report and open new ones for individual feature requests.

---

Added Fixed label.

[kevmoo]

Removed Area-IO label. Added Area-Library, Library-IO labels.