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+unsubscr...@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.
