New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Odd behavior of file.statSync() when file is a symlink #20389
Comments
I suggest we add a 'followLinks' argument to stat/statSync, to it matches how we do it other places, where we want to differentiate between working on the path directly and working on the resolved path. In this case it should default to 'true' for backward compatibility. Thoughts? cc @lrhn. |
Removed Priority-Unassigned label. |
We actually do what we promise, the documentation in file.dart says: * ## If path is a link so currently stat and statSync cannot return a FileStat object with type LINK. The only way to check for link is using FileSystemEntity.type and FileSystemEntity.typeSync with 'followLinks' set to true. Adding 'followLinks' to stat/statSync fits well with this pattern already used. |
Can we add a note or two to the |
FWIW, in POSIX, following symlinks is the normal behavior for Personally I'd prefer a |
On Windows we are currently not resolving symlinks. I'll fix that and update the docs as my first step. |
… calls. Also clarify documentation. TEST=Updated tests to cover stats() calls on symlinks. Bug: #20389 Change-Id: I8555bacc2f83cad024ad8ef7c2f23aa97069ed2e Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/218671 Reviewed-by: Alexander Aprelev <aam@google.com> Commit-Queue: Brian Quinlan <bquinlan@google.com>
Adding a I think that @jamesderlin 's proposal of having a Any thoughts? |
|
@eernstg Making |
I don't know any details about static FileStat statSync(String path) {
final IOOverrides? overrides = IOOverrides.current;
if (overrides == null) {
return _statSyncInternal(path);
}
return overrides.statSync(path);
}
|
Let me take a step back - I don't understand why we can't add a new method to a widely used class. Is that because a subclass might already define the same method but, for example, with a different signature? If that is the issue, then wouldn't the same issue exist when adding |
The typical problem with adding methods is if there is a derived class that In this case, a notable implementation of |
It might be OK to implement |
Consider this code:
(assume real == a string path to a symlink on a Mac)
var file = new File(real);
print(file);
var stat = file.statSync();
print(stat); // <===== here's the bug. it says FILE, but I would imagine it to say LINK
var isLink = stat.type == FileSystemEntityType.LINK;
print("this should be true: $isLink"); // <=== isLink is false
Expected: isLink is true
The text was updated successfully, but these errors were encountered: