-
Notifications
You must be signed in to change notification settings - Fork 84
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
libindex: add fallback path for O_TMPFILE not being supported #1292
Merged
Merged
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains 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
This file contains 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
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,8 @@ | ||
//go:build !unix | ||
|
||
package libindex | ||
|
||
// FixTemp is a no-op. | ||
func fixTemp(d string) string { | ||
return d | ||
} |
This file contains 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
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,18 @@ | ||
package libindex | ||
|
||
import ( | ||
"os" | ||
) | ||
|
||
// FixTemp modifies "dir" according to the documented defaults. | ||
// | ||
// See [NewRemoteFetchArena]. | ||
func fixTemp(dir string) string { | ||
if dir != "" { | ||
return dir | ||
} | ||
if d, ok := os.LookupEnv("TMPDIR"); ok && d != "" { | ||
return d | ||
} | ||
return "/var/tmp" | ||
} |
This file contains 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
Oops, something went wrong.
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.
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.
Hey @hdonnay, do you mind elaborating on this or rephrasing the comment? I'm having a hard time grokking it.
I couldn't find a reason
"/proc/self/fd"
was required for "unlinking" temporary files. I'm also not sure what unlinking in this context means; my assumption based on the word choice would be that the implementation does some sort of symlinking and we need to unlink them at some point, but I don't think that's the case.I'm particularly confused by this. If we're on Linux, do other temporary files get unlinked when we create our temporary files?
fwiw, I'm not sure if others do this, but I know Ross and I both run the ACS Scanner on macOS devices, so sorting this out would help us out a lot (in other words, I'm not trying to be pedantic with this comment 🙂)
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.
(also happy to move this discussion to another PR or elsewhere if we want to unblock merging 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.
No worries.
"Unlink" in this context is a filesystem/syscall term-of-art: it means making a name no longer visible. This isn't exactly deleting a file because the semantics change based on the the type of object, the underlying filesystem, and outstanding file descriptions. Out of a combination of battle scars and habit, I tend to say "unlink" when I'm specifically thinking of
unlink(2)
.With regards to
/proc/self/fd
, that's a directory containing magic symlinks (actual terminology, seesymlink(7)
) representing open file descriptors. Opening one of them creates a new file descriptor backed by a new file description (see the NOTES section ofopen(2)
). This means that unlikedup(2)
, the uses of the two file descriptors are completely independent (e.g. seeking one will not change the offset on the other).The Linux code uses this to open files that aren't linked into the filesystem (meaning they'll never outlast the process, because only the process has them open) but can still be reopened as many times as needed to create independent file descriptors.
AFAICT, there's not a way to do this on OSX. Looking at FreeBSD man pages,
fdescfs(5)
acts the same way but only if mounted withnodup
, which I don't think is the default. There is mention on that manpage about aO_EMPTY_PATH
toopenat(2)
, but I can't find any information on whether that exists on OSX and don't have a machine to test with. To work around this, the code simply doesn't unlink the file and re-opens it by name as needed. The downside is that the files are only removed as long as the program shuts down cleanly.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 the detailed explanation! I need to dive deeper into all this info, so please feel free to consider this discussion non-blocking for the PR