Skip to content

Use stat Instead of lstat #697

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

Merged
merged 1 commit into from
Jun 4, 2021
Merged

Conversation

CodaFi
Copy link
Contributor

@CodaFi CodaFi commented Jun 4, 2021

Using lstat here will do the wrong thing when the input path is a symlink since it's going to give us mod time info on the symlink instead of the file it references. Since mod time updates are intentionally not propagated across links, this has the potential to cause us to miscompile if a file's contents change on disk but the symlink passed as input hasn't actually changed. It also has the potential to defeat the incremental build when build systems that generate symlinks on every build interact with the driver.

On Darwin (and, technically, other UNIX-likes) the fix is simple: use stat instead of lstat which will resolve symlinks for us. On Windows the answer is... complicated. Instead, on the fallback path, resolve symlinks before retrieving the modification time of the file.

rdar://78828871

@CodaFi CodaFi requested a review from artemcm June 4, 2021 02:03
@CodaFi
Copy link
Contributor Author

CodaFi commented Jun 4, 2021

This isn't quite finished yet, just wanted to solicit opinions about the approach, particularly on Windows.

CC @compnerd

@CodaFi CodaFi requested a review from compnerd June 4, 2021 02:03
@compnerd
Copy link
Member

compnerd commented Jun 4, 2021

Going through Foundation means that it should do the right thing, and if it doesn't we should fix it in Foundation. That said, generally, you don't want to use stat and there is no real lstat on Windows. However, the stat behaviour on Windows isn't the Unix behaviour, and we need to manually chase the symlink :-(. Implementing the default behaviour of chasing the symlinks is possible, though slightly expensive (recursive open + ioctl) if we really need. I think that this approach is the simplest to implement while being correct and generally portable.

@CodaFi CodaFi force-pushed the statistically-speaking branch from f0a4f59 to 2639e2e Compare June 4, 2021 04:47
@CodaFi
Copy link
Contributor Author

CodaFi commented Jun 4, 2021

Alright, good to go

@CodaFi CodaFi force-pushed the statistically-speaking branch from 2639e2e to 9984dd9 Compare June 4, 2021 04:51
Using `lstat` here will do the wrong thing when the input path is a symlink since it's going to give us mod time info on the symlink instead of the file it references. Since mod time updates are intentionally not propagated across links, this has the potential to cause us to miscompile if a file's contents change on disk but the symlink passed as input hasn't actually changed. It also has the potential to defeat the incremental build when build systems that generate symlinks on every build interact with the driver.

On Darwin (and, technically, other UNIX-likes) the fix is simple: use stat instead of lstat which will resolve symlinks for us. On Windows the answer is... complicated. Instead, on the fallback path, resolve symlinks before retrieving the modification time of the file.

rdar://78828871
@CodaFi CodaFi force-pushed the statistically-speaking branch from 9984dd9 to 5ee692c Compare June 4, 2021 04:59
@CodaFi
Copy link
Contributor Author

CodaFi commented Jun 4, 2021

@swift-ci test

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants