This repository was archived by the owner on Apr 26, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 8
Conversation
Summary: I don't know that this is strictly necessary: in practice what seems to happen when you modify a file that's actually a symlink is that we modify the underlying file (that is, `open(f, 'w')` opens the file that the symlink points to, and leaves the actual link untouched). And when we try to modify the file the second time, under its new name, then all the codemods have already been applied via the symlink so it's a noop, and all is good. But I don't know if that's posix standard, and anyway it seems confusing. Now we notice symlinks and just skip over them. Test Plan: make test Reviewers: benkraft Subscribers: davidflanagan, carter Differential Revision: https://phabricator.khanacademy.org/D41041
@csilvers
csilvers
force-pushed
the
symlinks
branch
from
January 23, 2019 20:11
9e72a91 to
bd87570
Compare
csilvers
commented
Jan 23, 2019
Member
Author
@benjaminjkraft sez: "Sadly this will break the (admittedly fragile) way I cached resolve_paths -- it depends on sharing the same path-filter function object across suggestor runs, whereas now we'll have a new one each time (even if the root doesn't change). Honestly the easiest thing if this is an issue is probably to remove the caching; pruning directories makes path resolution fast enough that it doesn't really matter anymore."
benjaminjkraft
commented
Jan 23, 2019
Contributor
Yeah. As we discussed I think this is philosophically sensible. I think either removing the caching (assuming perf is ok), or improving it such that it will work right, is a good idea to clean up the code. It's a bigger change (at least in the latter case) but I don't think it will make things net-messier.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
I don't know that this is strictly necessary: in practice what seems
to happen when you modify a file that's actually a symlink is that we
modify the underlying file (that is,
open(f, 'w')opens the filethat the symlink points to, and leaves the actual link untouched).
And when we try to modify the file the second time, under its new
name, then all the codemods have already been applied via the symlink
so it's a noop, and all is good.
But I don't know if that's posix standard, and anyway it seems
confusing. Now we notice symlinks and just skip over them.