> I interpret that to mean you are changing the umask before running `go test`. That is, you might run `go test` with different umask values and don't want the cached results to ignore the umask value. As did Ian if I correctly understood their reply. The discussion then evolved into how a specific unit test can safely change the umask without affecting other unit tests. Running unit tests with different umask values is a different problem from how to write unit tests that modify the umask value.
That is correct. Unfortunately there seems to be a lack of knowledge in some cases of what umask is and how it behaves, which is why the discussion got sidetracked. > At this point it is unclear, at least to me, what problem you are trying to solve. I want go test to invalidate its cache when the umask is changed, i.e. I want the following sequence of commands to work correctly: $ umask 002 $ go test ./... $ umask 022 $ go test ./... # should not use cache $ go test ./... # should use cache Currently, the go test cache does not record the umask, so it incorrectly re-uses the cached test results in the second invocation of go test. It should instead invalidate the cache. Note that go test does record the external files used by the tests and the external environment variables used by the tests, and so it correctly invalidates the cache when any of them change. I would like the cache to also be invalidated when the external umask changes. Alternately put, go test already has special case code for external changes to files and environment variables, and I would like extend that to external umask changes too. Hope this makes my request clearer. I'd be delighted to submit at CL to do this (it's probably 10-20 lines of code with almost no performance penalty [1]), but I want to check that it has a reasonable chance to being accepted before I start the work. [1] The performance cost is two very fast syscalls during startup. On Tuesday, September 17, 2024 at 10:49:12 AM UTC+2 Kurtis Rader wrote: > You wrote earlier: > > > Currently changing the umask does not invalidate go test's cache, so I > get incorrect test results if I change the umask and re-run go test > > I interpret that to mean you are changing the umask before running `go > test`. That is, you might run `go test` with different umask values and > don't want the cached results to ignore the umask value. As did Ian if I > correctly understood their reply. The discussion then evolved into how a > specific unit test can safely change the umask without affecting other unit > tests. Running unit tests with different umask values is a different > problem from how to write unit tests that modify the umask value. At this > point it is unclear, at least to me, what problem you are trying to solve. > > On Tue, Sep 17, 2024 at 1:33 AM twp...@gmail.com <twp...@gmail.com> wrote: > >> umask cannot be set in subtests for two reasons: >> 1. It is a process-wide global variable stored by the operating system. >> Changing the umask in a test changes the umask for the entire process, i.e. >> it changes the umask for all tests. >> 2. It is not possible to set and restore the umask atomically. This makes >> it inherently racy for concurrent programs. >> >> To learn more about umask, and why it is special, please read the man >> page <https://man7.org/linux/man-pages/man2/umask.2.html>. >> On Monday, September 16, 2024 at 5:34:29 PM UTC+2 Jason Phillips wrote: >> >>> Why can't it be set within subtests? Note that subtests (like regular >>> tests) aren't run in parallel unless you explicitly call t.Parallel(). >>> >>> On Friday, September 13, 2024 at 6:35:15 PM UTC-4 twp...@gmail.com >>> wrote: >>> >>>> > Personally, I would approach this kind of thing by writing a test that >>>> sets the umask to various different values and invokes subtests with >>>> each umask value. >>>> >>>> I would love to do this but umask is a process global (as far as I >>>> understand it) and so can't be set within subtests. >>>> >>>> On Saturday, September 14, 2024 at 12:33:19 AM UTC+2 Ian Lance Taylor >>>> wrote: >>>> >>>>> On Fri, Sep 13, 2024 at 3:03 PM twp...@gmail.com <twp...@gmail.com> >>>>> wrote: >>>>> > >>>>> > tl;dr: umask is a system-wide global that affects go tests and >>>>> should be considered when validating go test's cache. >>>>> > >>>>> > >>>>> > Motivation: >>>>> > >>>>> > I'm the author of a popular open source project that writes files to >>>>> the user's home directory and cares about getting exact file permissions >>>>> correct. The file permissions depend on the the current umask setting. As >>>>> umask is a process global variable, it cannot be set for individual >>>>> tests, >>>>> and so separate tests are needed for different umasks. >>>>> > >>>>> > Currently changing the umask does not invalidate go test's cache, so >>>>> I get incorrect test results if I change the umask and re-run go test. >>>>> > >>>>> > >>>>> > Suggested solution: >>>>> > >>>>> > Include umask as an op in go test's id calculation. >>>>> > >>>>> > >>>>> > Next steps: >>>>> > >>>>> > * Is this something that the Go project would consider? >>>>> > * If so, I would be happy to submit a CL. >>>>> >>>>> Personally, I would approach this kind of thing by writing a test that >>>>> sets the umask to various different values and invokes subtests with >>>>> each umask value. That way the test is independent of the external >>>>> environment. >>>>> >>>>> In general our approach has been that if your test intrinsically >>>>> depends on the external environment, then you should run it with >>>>> -test.run=1 to disable the test cache. >>>>> >>>>> Ian >>>>> >>>> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/c9dcf1bb-25ae-4e58-8714-66325077c2d1n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/golang-nuts/c9dcf1bb-25ae-4e58-8714-66325077c2d1n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > > > -- > Kurtis Rader > Caretaker of the exceptional canines Junior and Hank > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/54562ddc-d526-437d-b49f-27a89962c334n%40googlegroups.com.
