Unclear specification of File's fullPath, fullPathSync, and name

[peter-ahe-google]

The File interface contains the following:

  /**
   * Get the canonical full path corresponding to the file name. The
   * [fullPathHandler] is called when the fullPath operation
   * completes.
   */
  String fullPath();

  /**
   * Synchronously get the canonical full path corresponding to the file name.
   */
  String fullPathSync();

  /**
   * Get the name of the file.
   */
  String get name();

This leads to the following questions:

1. What is returned by fullPath?
2. Does the returned valued of fullPathSync use platform dependent file delimiters?
3. What does "canonical" mean? Generally, the concept of canonical file names is broken. In both Windows and Unix, you can refer to the "same" file using different paths without having the ability to say one is the canonical name. If the intent is to remove symlinks, please reconsider. Removing symlinks from file paths is generally harmful as it is a common idiom in Unix system administration to setup links to hide "implementation details" such as specific disk that stores a file.
4. What is the name of a file?

I suggest the following:

  /**
   * Get the absolute(define this) normalized(define this) path corresponding to this file. The
   * [fullPathHandler] is called with one argument, the absolute normalized path, when the fullPath operation
   * completes.
   */
  void fullPath();

  /**
   * Synchronously get the absolute(define this) normalized(define this) path corresponding to this file.
   */
  String fullPathSync();

  /**
   * Get the path of this file as was provided when this file object was created.
   */
  String get name();

However, I question the need for an async version of fullPath. This path should be known at construction time without calling any blocking IO.

Furthermore, the File interface lacks a comment which describes its purpose. Finally, the documentation of the constructor is redundant.

[whesse]

The key reason for introducing fullPath was to get absolute paths from relative paths. The idea is to use the OS's notion of a full path by using the platform's full path method. I'll look into all these specification issues.

---

Set owner to @whesse.
Added Area-Library, Accepted labels.

[peter-ahe-google]

On Unix, what is the platform's full-path method?

[peter-ahe-google]

My comment #­2 reminds me: what happens if the full path isn't available? I think it is possible to be running in a directory that you cannot read. See the error codes of getcwd(2).

[whesse]

We are using the realpath() method on unix, which does resolve symbolic links, and can return failures due to access violations or other problems. I don't see a reasonable alternative that does everything except resolve symbolic links. The alternative would be to just combine the CWD with a relative path, and resolve . and .. using the Join method of a Path library (following the semantics of URI path components). This doesn't do IO or use the operating system at all.

Do you think there are other possibilities? Otherwise, which of these two do you think should be the semantics of fullPath?

If we do go to the OS, then we should throw an exception, or call an error handler, with the system error message corresponding to any actual error code we get.

[peter-ahe-google]

I prefer combining CWD.

[DartBot]

This comment was originally written by jjinux...@google.com

---

By the way, I had a hard time finding fullPath because it didn't have the word "absolute" in it, and because it was only present in File, not in Directory (I happened to be working with directories at the time).

[floitschG]

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

[whesse]

We want to make a clear specification of what fullPath does, or replace it with other methods. We probably should have a method that gets absolute paths, with an appropriate name, and a method that resolves symbolic links and .. directories, with an appropriate name.

These methods should be available on all of File, Directory, Link, and maybe FileSystemEntity. Redirecting bugs about "Directory missing FullPath" here.

[whesse]

Issue #8318 has been merged into this issue.

[whesse]

Issue #8992 has been merged into this issue.

[sgjesse]

Added this to the M5 milestone.

[sgjesse]

Removed this from the M5 milestone.
Added this to the M6 milestone.

[sgjesse]

This should move to FileSystemEntity. "full" should be renamed to "absolute" and the comment updated to say that this is the absolute path provided by the OS.

[larsbak]

Removed this from the M6 milestone.
Added this to the M7 milestone.

[whesse]

This is being moved to FileSystemEntity.resolveSymbolicLinks, and a different FileSystemEntity.absolutePath method will be added, that will simply join the current working directory with relative paths, without accessing the filesystem.

We think that people looking for an absolutePath method want the second behavior, because the resolveSymbolicLinks behavior gives unexpected results and can be a performance bottleneck.

The path package also provides absolutePath, but we need to provide it on the classes File, Directory, and Link so that people can find it, and don't use the former fullPath method instead.

---

Added Started label.

[whesse]

Fixed in r27612. absoutePath and resolveSymbolicLinks have both been added to FileSystemEntity, with full documentation and testing.

---

Added Fixed label.

[kevmoo]

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