--- Log opened Fri Oct 16 00:00:48 2020
12:19 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #utreexo
12:22 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 260 seconds]
12:40 < adiabat> argh so it looks like a file sync thing
12:40 < adiabat> where if you write some bytes to a file, then seek backwards, then write some more...
12:41 < adiabat> it just skips the seek part and just keeps writing ahead
12:41 < adiabat> but if you write, sync, seek, write, it goes to the place you said to
12:42 < adiabat> to me that's a bug in go std lib... I mean if you say n, err := file.WriteAt(bytes, 20)
12:42 < adiabat> and instead of putting it at location 20, it puts it at location 5735
12:43 < adiabat> then err should not be nil!
12:44 < adiabat> also just don't write anything instead of writing it to the wrong place.
12:45 < adiabat> "WriteAt" feels like the "At" is just as important as the "Write", not "Write, (oh and if you get a chance, at this location)"
12:46 < adiabat> blarg anyway just frustrated that I spent so long figuring this problem out because I did not think the file io could do such a weird thing
12:49 < adiabat> ... aha, some fine print!
12:49 < adiabat> "The behavior of Seek on a file opened with O_APPEND is not specified"
12:49 < adiabat> well good to know, maybe also return an error then?
12:50 < adiabat> "If file was opened with the O_APPEND flag, WriteAt returns an error." nope, that one definitely does not happen
12:50 < adiabat> so, that's maybe a bug in go stdlib, or at least a documentation bug
13:12 < ja> one could argue that if you WriteAt after you Seek (which was undefined behaviour), all bets are off
13:42 < adiabat> I didn't mix them though
13:42 < adiabat> I tried switching from seek / write to writeAt
13:42 < adiabat> there's sortof an issue but they closed it
13:42 < adiabat>  https://github.com/golang/go/issues/30716
13:43 -!- belcher_ is now known as belcher
13:44 < ja> ah, did you see the commit that resolves it, that is the commit recarding O_APPEND/WriteAt erroring: https://github.com/golang/go/commit/c7f7f59368c3a964b8214018dc5100806b243938
13:45 < ja> now that we know which code is supposed to trigger the error, it would be easier to find out why it doesn't trigger on your machine
13:46 < ja> ooooh, it is only in go 1.13 and up! which version are you at?
13:46 < adiabat> ah shoot it's fixed in go 1.15.3
13:46 < adiabat> yeah
13:46 < adiabat> I'm on 1.12 or something
13:46 < adiabat> ok shoot I need to update then
13:46 < ja> now, go 1.15.3 is the latest it is in, the earliest is at the right
13:46 < adiabat> well in this case I just got rid of O_APPEND
13:46 < ja> *no
13:47 < adiabat> yeah 1.12 so no backport
13:47 < adiabat> hah
13:48 < adiabat> what does O_APPEND even do..?  Everything works fine with it taken out
13:48 < adiabat> it still expands the file if you try to write past the end the same way
13:49 < ja> i always thought it would seek to the end of the file after opening, and that's it
13:50 < adiabat> oh.  that's not too useful.  especially when it messes up other stuff :)
13:50 < ja> but you can see the actual glibc docs using "man 2 open"
13:50 < adiabat> hm yeah in this case I'm explicitly seeking to the beginning after opening anyway
13:50 < ja> oh, no, those are linux doc pages
13:51 < adiabat> huh " Before each write(2), the file offset is positioned at the end of the file" yeah that's not what I want
13:51 < adiabat> I guess I need to read the linux stuff as well
13:52 < adiabat> I assumed O_APPEND meant it would expand the size of the file when you try to write past the end, like with Truncate()
13:52 < adiabat> yeah "always write to the end no matter where you say to write" is definitely not going to work for the TTL values :)
13:52 < adiabat> ok well now it works
13:53 < ja> yeah it seems my assumptions were broken also :O i mean, if it seeks to the end before every write, then seek becomes totally useless? that is weird
13:53 < adiabat> or there's some other bug I guess but hopefully the rest are just little things
--- Log closed Sat Oct 17 00:00:49 2020