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.
--
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.
