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)).
Write should not expect that req.Offset is always within the current
file size, it is entirely valid to read/write any offset you like.
(e.g. from lseek(2): The lseek() function allows the file offset to be
set beyond the end of the file (but this does not change the size of the
file). If data is later written at this point, subsequent reads of the
data in the gap (a "hole") return null bytes ('\0') until data is
actually written into the gap.)
--
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.
