I think you are probably going to get better results by just filing a
proposal. That's the normal process which will end in a definite result one
way or the other, while mailing list threads tend to go in circles,
eventually.
On Tue, 17 Sept 2024 at 13:08, twp...@gmail.com <twpa...@gmail.com> wrote:
>
> On Tuesday, September 17, 2024 at 12:44:42 PM UTC+2 Stephen Illingworth
> wrote:
>
> If the only problem is that the cache is getting in the way then you can
> run the tests such that test cache is not used. The idiomatic way is to use
> -count=1 on the test command line
>
> I would do this:
>
> go test -count=1 <umask tests>
>
> And then:
>
> go test <other tests>
>
>
> I am aware that I can work around go test cache's incorrect behavior by
> disabling the cache. This is annoying for several reasons:
> * I have to manually maintain a list of tests that are affected by the
> umask.
> * I have to run go test twice.
> * I don't get the speed-ups of caching when the caching should work, which
> slows down my development cycle.
>
> Note that all tests that write files are affected by umask, even if many
> people don't realize this. To demonstrate this, find a project that calls
> testing.T.TempDir() and run:
>
> $ umask 777
> $ go test ./... -count=1
>
> The odds are that the tests will fail.
>
> However, I want to make go test cache's behavior more correct for a case
> where it is currently incorrect for no measurable performance penalty. What
> are the reasons for *not* doing this?
>
>
> On Tuesday 17 September 2024 at 11:25:40 UTC+1 twp...@gmail.com wrote:
>
> > Should work, AIUI, even with the issues you mention. Or is there
> something else going on that I'm unaware of?
>
> The problem is not running the tests. The problem is that the test cache
> is not invalidated correctly.
>
> On Tuesday, September 17, 2024 at 11:52:35 AM UTC+2 Axel Wagner wrote:
>
> On Tue, 17 Sept 2024 at 10:33, 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.
>
>
> I might be misunderstanding something, but neither of these seems to
> actually be a problem. Tests are not run concurrently, unless explicitly
> requested by calling `t.Parallel()`. The same goes for sub tests, I
> believe. So, simply doing
>
> func TestOne(t *testing.T) {
> defer syscall.Umask(syscall.Umask(0))
> // test goes here
> }
> func TestTwo(t *testing.T) {
> defer syscall.Umask(syscall.Umask(0777))
> // test goes here
> }
>
>
> 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>
> .
>
> --
> 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/27617075-a38b-4e01-8412-b290aab3f906n%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/27617075-a38b-4e01-8412-b290aab3f906n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAEkBMfFJern%2BFvBTrvxqTd6GyONuKF4hvgusx042fc%3DPSOjyxg%40mail.gmail.com.
