On 07/09/2016 10:39, Dan Kortschak wrote:
On Wed, 2016-09-07 at 09:22 +0100, Julian Phillips wrote:
On 07/09/2016 01:08, Dan Kortschak wrote:
> On Wed, 2016-09-07 at 09:05 +0930, Dan Kortschak wrote:
>> > These are just the flags passed to open. If you want to act on the
>> > truncate flag, do it once within open, not on every single
>> subsequent
>> > call to write.
>> >
>> That makes sense. So, we're narrowing down on my field of ignorance.
>>
>> Am I right in thinking then that I should be just doing
>> `append((*f)[:off], b...)[:len(*f)+len(b)]` in the body of
>> Bytes.WriteAt?
>>
> It turns out that while that is an error, it is not the cause of the
> problem.
>
> The truncate operation that is causing the later out of bounds is the
> explicit call to truncate(0):
>
> err = f.Truncate(0)
> if err != nil {
> log.Fatalf("unexpected error truncating rw buffer: %v", err)
> }
> _, err = f.Write(data) // Causes panic in server below.
>
> The write causes a WriteAt(data, off) where off is the size of the file
> prior to the truncate call.
>
> So the question is how do I ensure that the kernel sees that the file
> size has been reduced.
The Truncate call has done that, however Write writes to the file
offset, not the end of the file - so you need to change the file
offset.
The truncate syscall doesn't change the file offset, so you need a
Seek
to do that (see truncate(2), lseek(2)).
That is at odds with the behaviour of this program
https://play.golang.org/p/wcazRYxRzy
Not here. The resulting file is 31 bytes, with 19 leading NULs. You
won't see the NULs if you just cat the file though.
(though reading ftruncate(2) does point to further errors in my
implementation).
--
Julian
--
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.
For more options, visit https://groups.google.com/d/optout.
