linuxemu: some programs cannot write more than 255 bytes to a file.

[GoogleCodeExporter]

"some programs" in this case means bash's redirection and ed's w command.

this is a new-ish problem. i was in the habit of using cat > /9/dev/snarf 
inside linuxemu. typical data size was up to 1kb. it used to work, but now cat 
just quits after the first line, if the line is longer than 255 bytes. it is 
not specific to the snarf buffer, cat > ~/tt also quits after 255 chars. 
exactly 255 bytes are written to the file when this happens. cat's exit status 
is 0, no error is reported, but then cat quits before eof.. ?.? ed (gnu ed) 
actually quits as soon as it's started, even if the file length is zero.

on the other hand, openttd can save games no problem, and it's saves are 
120-180kb.

this started without linuxemu changing, so i suppose it's something in the 
kernel. if memory serves, it was fine before the work done for go.

not sure if related: at the same time as this bug appearing, a different aspect 
of linuxemu has improved. opera now runs for much longer before locking up.

Original issue reported on code.google.com by tereniao...@gmail.com on 21 Jun 2013 at 11:42

[GoogleCodeExporter]

run linuxemu with syscall tracing.

Original comment by cinap_le...@felloff.net on 22 Jun 2013 at 3:19

[GoogleCodeExporter]

still alive?

Original comment by cinap_le...@felloff.net on 2 Aug 2013 at 2:04

[GoogleCodeExporter]

aye, was just looking for this. now all that is happening is pastes in xterm 
are still truncated to 255 chars, but cat for example doesn't exit when pasted 
into.

i never got around to the syscall tracing, especially as it has to be done with 
x programs. can't concentrate. i'm not sure this is worth looking into; if I 
can quieten my linux box i'll probably leave it running 24/7 and just vnc in.

Original comment by tereniao...@gmail.com on 2 Aug 2013 at 6:18

[GoogleCodeExporter]

Type-BlackjackAndHookers because only Equis is affected. Status NeedsTesting, 
if anybody cares enough. I've stopped using equis.

Original comment by tereniao...@gmail.com on 9 Aug 2013 at 9:58

• Changed state: NeedsTesting
• Added labels: Priority-RockBottom, Type-BlackjackAndHookers
• Removed labels: Priority-Low, Type-FrontFellOff

[GoogleCodeExporter]

needs testing what? there where no changes made that need testing.

Original comment by cinap_le...@felloff.net on 30 Sep 2013 at 2:21

[GoogleCodeExporter]

Behaviour is clearly broken, but it's not clear exactly what is broken.

Original comment by tereniao...@gmail.com on 2 Oct 2013 at 9:59

[GoogleCodeExporter]

>>/lib/troll

Original comment by cinap_le...@felloff.net on 9 Oct 2013 at 11:23

[GoogleCodeExporter]

still alive?

Original comment by cinap_le...@felloff.net on 28 Oct 2013 at 4:39

[GoogleCodeExporter]

steps to reproduce:

* start xterm
* run command in that xterm: cat > /9/dev/snarf
* run opera, load http://aiju.de/misc/optimize
* select all text in the paragraph under the 'silver rule' heading; no newlines
* paste into xterm
> appears to paste
* press return in xterm
> prompt! cat has exited.
* echo $? (cat's exit status)
> it is 0
* in plan 9, paste
> paste text is this, with no newline:

Optimization usually results in a decrease of portability and code readability. 
Tiny little 0.5% optimizations usually aren't worth doing. Many people write 
xor eax, eax instead of the more readable mov eax, 0 for "performance reasons", 
even in cases wher

Original comment by tereniao...@gmail.com on 28 Oct 2013 at 7:20

[GoogleCodeExporter]

I forgot to add, running a second cat command in that xterm returns instantly.

Original comment by tereniao...@gmail.com on 28 Oct 2013 at 7:26

[GoogleCodeExporter]

Cause traced to Linuxemu TTY subsystem: it's designed for keyboard input, 
pasting into an xterm sends data through it much faster than it is designed 
for. 

Fixing this would require an even deeper study of the nasty subject that is the 
Unix TTY device, and would contribute nothing to 9front itself. Thus: WontFix.

Original comment by tereniao...@gmail.com on 29 Oct 2013 at 1:59

• Changed state: WontFix