Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Make polling use the symbolic link target's LastWriteTime #55664
Make polling use the symbolic link target's LastWriteTime #55664
Changes from 2 commits
f515710
08233ba
d780995
ac4a845
b4895ad
ebb0326
1164e33
98b737a
75fcf96
144335a
9c50a3a
b2f9bad
d8d143a
c7e28d4
5b85631
5c27cae
19dd9c3
8c1b3a2
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How is this unsupported on browser? Is the whole assembly not supported on browser?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this project references System.IO.FileSystem.Watcher and that is not supported in browser:
runtime/src/libraries/System.IO.FileSystem.Watcher/Directory.Build.props
Line 6 in 7aaffcb
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see, so then should we add a runtime assembly for Browser that throws PNSE?
cc: @marek-safar @steveisok
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/cc @lewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes which is what this setting does
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This setting doesn't generate a PNSE automatically, this setting is just to add an assembly attribute for the platform analyzer. Unless something changed since last time I did it, in order to generate PNSE we need to add a
-Browser
tfm and then set the flag to generate a pnse when TargetsBrowser == true. So then it seems like we should do that.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for catching this, I've addressed @safern's comment in 75fcf96, please let me know if something else (related to mark the project as unsupported in Browser) needs to be done.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jozkee have you considered keeping all these libs .NET Standard 2.0 and referencing the code that defines
ResolveLinkTarget
(and other things if needed)? We are already doing something like this forMicrosoft.IO.Redist
which targetsnet471
. I am just wondering how much effort it would require to keep it NS2.0.@jeffhandley @ericstj how long do we plan to keep targeting
netstandard2.0
andnet461
for theMicrosoft.Extensions*
libs?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At the moment we have no plans for dropping
netstandard2.0
(and therefornet461
) from the extensions. Perhaps it's something that could be considered in the future if this limitation hinders development considerably. They were intentionally omitted from aspnet/Announcements#324. cc @davidfowl @DamianEdwards @maryamariyanThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, we're keeping ns2.0 and net461 until further notice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can do a different (and more efficient) approach to get the target's Last write time, see @ericstj's suggestion #55664 (comment).
But (not) saving a couple of allocations is not a big issue considering that the performance penalty is relatively low compared to other pieces of the code that allocate much more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jozkee I wanted to know whether it would be possible to make this fix work for all TFMs (6 + NS2 + net461), because currently, it's going to work only for .NET 6.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is, but we can defer fixing this on other TFMs if no one is asking for it.
Do you think we can take a dependency on MS.IO.Redist here to utilize the same set of Symbolic Link APIs in order to fix this in ns2.0?
cc @jeffhandley.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think to fix on older TFMs it needs more than just MS.IO.Redist. I believe the implementation of the IO API you are using here (or would add) would depend on the system-native PALs which we don't consider part of the public API. Having a package depend on those is fragile at the least, and might not even work if the versions of those don't have the exports you need on older frameworks. Adding private copies of the system-native PALs (similar to what System.IO.Ports does) is expensive too. Something to consider around OOB'ing our IO API.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ahh, good info @ericstj. So far, we don't have any requests to have this fix apply to previous versions; I'm OK with this being net6.0+ until such requests come in.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will this raise new exceptions if the target of the file is not reachable? Perhaps we can add a test case for that: watching a normal file, watching a non-existent file, watching a symlinked file, watching a symlink with non-existent target.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It shouldn't,
Exists
andLinkTarget != null
should guard for that.runtime/src/libraries/Microsoft.Extensions.FileProviders.Physical/src/Internal/FileSystemInfoHelper.cs
Lines 42 to 49 in 08233ba
However since these APIs are not atomic, it could be that the link gets deleted between LinkTarget and ResolveLinkTarget. I don't know if there's an atomic way to do this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's worse than just not being atomic, since you capture the
FileInfo
for the lifetime of the token, which might be long.Here's another scenario. Suppose that the symlink initially points at one target, but then is changed to point at a new target and that new target has a new modified time? I think that's actually the scenario in this issue. If you captured the
FileInfo
from the initial target you'd miss that change since you'd be checking the original target.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What happens if the symlinks chain goes through an area that you can't read?
In our world, baz.LinkTarget should resolve (to foo/bar). Does foo/bar then report Exists is false since it can't be read (the directory is no longer allowed to be traversed into)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bartonjs Yes, that's what I would expect. Therefore this should print false, unless that the FileInfo .ctor does some validation on inaccessible paths:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for addressing the link target feedback. Please consider adding test cases for the deleted link target cases, as they seem unique to this addition as it has to handle non-existent link targets, and link targets that get deleted / added.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the link target does not exists, we are returning the
LastWriteTimeUtc
from the link itself but I think that doesn't tell us anything, I will change it to returnDateTime.MinValue
instead (same thing we do when the file does not exists).Let me know if you think that could be problematic.
I also added the requested tests: 98b737a.