diff options
author | Russ Cox <rsc@swtch.com> | 2014-04-19 10:09:22 -0400 |
---|---|---|
committer | Russ Cox <rsc@swtch.com> | 2014-04-19 10:09:22 -0400 |
commit | 1d2c3c3945a229f896640b615b84f3d9a78e8b5a (patch) | |
tree | ebf07610a95891039b620acbab3dd960d8778211 /src/cmd/9660srv/9660srv.c | |
parent | d213189122bb3cd509cfe706240ffea528fee5f2 (diff) | |
download | plan9port-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 'src/cmd/9660srv/9660srv.c')
0 files changed, 0 insertions, 0 deletions