aboutsummaryrefslogtreecommitdiff
path: root/font/fixed/6x13.2800
diff options
context:
space:
mode:
authorRuss Cox <rsc@swtch.com>2014-04-19 10:09:22 -0400
committerRuss Cox <rsc@swtch.com>2014-04-19 10:09:22 -0400
commit1d2c3c3945a229f896640b615b84f3d9a78e8b5a (patch)
treeebf07610a95891039b620acbab3dd960d8778211 /font/fixed/6x13.2800
parentd213189122bb3cd509cfe706240ffea528fee5f2 (diff)
downloadplan9port-1d2c3c3945a229f896640b615b84f3d9a78e8b5a.tar.gz
plan9port-1d2c3c3945a229f896640b615b84f3d9a78e8b5a.tar.bz2
plan9port-1d2c3c3945a229f896640b615b84f3d9a78e8b5a.zip
acme: use buffered i/o to write file
Bakul Shah has observed corrupted files being written when acme writes over osxfuse to sshfs to a remote file system. In one example we examined, acme is writing an 0xf03-byte file in two system calls, first an 0x806-byte write and then a 0x6fd-byte write. (0x806 is BUFSIZE/sizeof(Rune); this file has no multibyte UTF-8.) What actually ends up happening is that an 0x806-byte file is written: 0x000-0x6fd contains what should be 0x806-0xf03 0x6fd-0x7fa contains zeros 0x7fa-0x806 contains what should be 0x7fa-0x806 (correct!) The theory is that fuse or sshfs or perhaps the remote file server is mishandling the unaligned writes. acme does not seem to be at fault. Using bio here will make the writes align to 8K boundaries, avoiding the bugs in whatever underlying piece is broken. TBR=r https://codereview.appspot.com/89550043
Diffstat (limited to 'font/fixed/6x13.2800')
0 files changed, 0 insertions, 0 deletions