fusefrontend: take ContentLock for truncate through node.SetattrHEADmaster

node.Setattr opens its own file handle and called truncate directly,
without ContentLock. truncate ends in doWrite, which documents that the
caller holds that lock, and file.Setattr and Allocate both take it.

Besides leaving a path truncate unserialized against concurrent writes,
this skipped the write-operation counter that ContentLock.Lock()
increments. isConsecutiveWrite() reads that counter to notice foreign
modifications, so an already-open handle kept assuming its next write
appends, skipped writePadHole() and grew the file past a short last
block. That block no longer decrypted, and every later operation on the
file failed with EIO.

Fixes #1024

0 files changed, 0 insertions, 0 deletions