cleahcim / go9p Goto Github PK
View Code? Open in Web Editor NEWAutomatically exported from code.google.com/p/go9p
License: Other
Automatically exported from code.google.com/p/go9p
License: Other
Shouldn't IOHDRSZ be 23 not 24?!?!
Original issue reported on code.google.com by [email protected]
on 14 Sep 2010 at 6:34
I'm starting to use go9p for a project, but i will need authenticated (and
preferrably encrypted) access, so it would be nice to have an authenticated
example of any of the srv/examples.
I'll try to hack one up, but i'm not sure what I need to do...
Original issue reported on code.google.com by [email protected]
on 22 Dec 2010 at 2:09
Before revision 102:49cad2d4591a (2 days ago) some source files,
p/clnt/stats_http.go and p/srv/stats_http.go, would not be
built on default, as Makefiles contained lines like:
STATS=
#STATS=stats_http.go
GOFILES=\
...\
$(STATS)\
As a result, net/http package, which is used in stats_http.go,
would have been linked into a go9p program only if STATS was
set to the non-default value.
Makefiles vanished as a part of the transition to the Go build
tool; now all go files within p/clnt and p/srv will be built
on default, i.e. also stats_http.go. I suggest to add a line to
the top of each of the stats_http.go files:
// +build ignore
which would exclude them from being built on default.
This would restore the old behavior and avoid net/http being
linked into each program using go9p. Users that want to use
the statistics could remove these lines temporarily.
Unrelated to the issue above, though related to stats_http.go,
i.e. the use of http.Handle() in statsUnregister() functions:
It seems that unregistering a Handle by specifying
a nil pointer is no longer possible since Go revision
11785:d739d7e8b0e6: "net/http: panic on duplicate
registrations". Now net/http will panic in such a case.
(I don't know if there is a way to unregister a http.Handle at all
...)
Michael
Original issue reported on code.google.com by [email protected]
on 13 Feb 2012 at 1:50
What steps will reproduce the problem?
1. Implement FOpenOp.Open for a file, always return an error
2. Add said file to a server
3. Read said file with "9p read <path-to-file>"
Attaching an example file server (fstest.go)
What is the expected output? What do you see instead?
I expect the read to fail, instead it succeeds.
Please provide any additional information below.
Adding a return instruction in p/srv/file.go:373 after the RespondError call
fixes the problem.
Original issue reported on code.google.com by [email protected]
on 23 Aug 2013 at 8:12
Attachments:
Thanks for go9p! I used it to rewrite a 9p server I had written in C, and
srv.File made it super-easy.
Unless I've missed something though, there's no way to tell the server to stop
listening and close the socket. I can understand why as many servers will be
happy to let the OS clean up the tcp socket after it exits.
However when using unix domain sockets, the OS doesn't clean up the socket file
and the server fails next time it runs ("address already in use").
It looks like the "go way" here is for the server to call Close() on the unix
socket once it is done. Go's net library will then take care of removing the
socket file.
My intention is to add a Stop() call to srv.Srv to facilitate this use case. Is
there anything I should keep in mind when working on the patch to improve it's
chance of being accepted?
Thanks,
-sqweek
Original issue reported on code.google.com by [email protected]
on 27 Nov 2013 at 1:43
# What steps will reproduce the problem?
Trying to create two different clients with mount causes a panic, due to a
double registration in the http package.
I've attached a test program that exhibits the problem, along with it's output
to stderr (nothing comes out on stdout). The original code that caused me to
notice the issue is here:
github.com/zenhack/cow9p
commit 78f0796f8e4f (which is current at the time of writing) causes the
problem.
# What is the expected output? What do you see instead?
Should successfully mount both filesystems, and exit normally without producing
any output. Instead, the http package causes a panic due to double registration
(see stderr.log)
What version of the product are you using? On what operating system?
hg revison 120, gc compiler (go9p was built with go get) on linux amd64.
# Please provide any additional information below.
It seems like the http package shouldn't even need to be pulled in unless
explicity asked for; I was a bit confused when I got a panic from a package I
didn't think I was using. Could the http stuff go in a sub-package?
Original issue reported on code.google.com by [email protected]
on 30 Dec 2012 at 3:23
Attachments:
I noticed Rob and Russ have been playing around with a 9p API for Go that seems
to overlap with go9p. Perhaps a merger is in order?
Original issue reported on code.google.com by [email protected]
on 6 Aug 2013 at 12:02
clnt.File should implement io.Seeker to keep up the 'file' illusion.
Original issue reported on code.google.com by [email protected]
on 30 Aug 2014 at 11:12
Read from a dir at Offset = 0 twice and you will get Ebadoffset instead of
rewinding the directory read.
diff -r 06555e13d0bc p/srv/fcall.go
--- a/p/srv/fcall.go Thu Nov 11 13:37:20 2010 -0700
+++ b/p/srv/fcall.go Mon Nov 15 10:44:55 2010 -0800
@@ -326,9 +326,13 @@
return
}
- if (fid.Type&p.QTDIR) != 0 && tc.Offset > 0 && tc.Offset != fid.Diroffset {
- req.RespondError(Ebadoffset)
- return
+ if (fid.Type&p.QTDIR) != 0 {
+ if tc.Offset == 0 {
+ fid.Diroffset = 0
+ } else if tc.Offset != fid.Diroffset {
+ req.RespondError(Ebadoffset)
+ return
+ }
}
(req.Conn.Srv.ops).(ReqOps).Read(req)
Original issue reported on code.google.com by [email protected]
on 15 Nov 2010 at 6:46
To fix, replace "os.Dir" with "os.FileInfo" and add a cast at line 144 ;D
Seriously, it would be nice to have the examples compiled by default, so
annoying bugs like these get noticed by anyone typing "make"
Original issue reported on code.google.com by [email protected]
on 26 Apr 2010 at 7:56
Good evening,
I've been playing around with go9p and libixp (http://repo.cat-v.org/libixp/)
and I think I spotted a bug when they interact.
To reproduce,
1. launch any of srv/examples on localhost:5640
2. run "ixpc -a 'tcp!127.0.0.1!5640' ls"
3. ixpc fails with "unknown user: 22"
cl and ls in clnt/examples are fine. With -d=1 on the server, I can see that
they send Tattach messages looking like
Tattach tag 0 fid 0 afid 4294967295 uname '' nuname 1001 aname ''
whereas ixpc does
Tattach tag 0 fid 1 afid 4294967295 uname 'louis' nuname 4294967295 aname ''
I understand that the go9p programs put the nil value in uname and rely on
nuname and that ixpc does the exact opposite.
I figured out 22 means EINVAL, the invalid user seems to be the 0xFFFFFFFF id.
As far as I know, this report could also be considered an issue with libixp.
I haven't tried connecting a go9p client and a libixp server over tcp.
Louis
Original issue reported on code.google.com by [email protected]
on 23 Jul 2014 at 8:29
examples not working after implementing io.Reader/io.Writer in rev 467f16f300db
marko@ributtalo ~/Build/go9p/p/clnt/examples $ ./read -addr="127.0.0.1:5645"
/myfile ()
this is my file2011/06/06 16:02:19 Error EOF
Original issue reported on code.google.com by [email protected]
on 6 Jun 2011 at 2:04
dirread9p is very useful for Read calls on directories. an example in go is
below, as i have used in my fileserver. it could just be called srv.Dirread.
type Dirgen func(uint64, interface{}) *p.Dir
func Dirread9p(req *srv.Req, gen Dirgen, i interface{}) {
var start uint64
var count uint32
p.InitRread(req.Rc, req.Tc.Count)
if req.Tc.Offset == 0 {
start = 0
} else {
start = req.Fid.Diroffset
}
b := req.Rc.Data
for len(b) > 0 {
d := gen(start, i)
if d == nil {
break
}
sz := p.PackDir(d, b, req.Conn.Dotu)
if sz == 0 {
break
}
b = b[sz:]
count += uint32(sz)
start++
}
req.Fid.Diroffset = start
p.SetRreadCount(req.Rc, uint32(count))
req.Respond()
}
Original issue reported on code.google.com by [email protected]
on 10 Mar 2014 at 12:34
from 9p(2):
Because implementing the full walk message is intricate
and prone to error, the helper routine walkandclone
will handle the request given pointers to two functions
walk1 and (optionally) clone . Clone, if non-nil, is
called to signal the creation of newfid from oldfid.
Typically a clone routine will copy or increment a ref-
erence count in oldfid's aux element. Walk1 should
walk fid to name, initializing fid->qid to the new
path's qid. Both should return nil on success or an
error message on error. Walkandclone will call respond
after handling the request.
Original issue reported on code.google.com by [email protected]
on 10 Mar 2014 at 12:36
if the iounit of the auth fid is not set, Tread messages will get packed with a
0 read count, resulting in auth always failing on the first read of the auth
fid.
patch follows.
==============
diff -r 630c71178faf p/clnt/mount.go
--- a/p/clnt/mount.go Wed May 14 13:19:14 2014 -0600
+++ b/p/clnt/mount.go Sat Aug 30 06:26:39 2014 +0000
@@ -24,6 +24,7 @@
return nil, err
}
+ fid.Iounit = clnt.Msize - p.IOHDRSZ
fid.User = user
fid.walked = true
return fid, nil
Original issue reported on code.google.com by [email protected]
on 30 Aug 2014 at 6:26
if you get a Fid from say, clnt.Auth, it is practically useless. i would like
to pass the auth fid to factotum, but my factotum library needs a io.ReadWriter
to speak to the server. you can't simply construct a File from a Fid, which
would meet the io.ReadWriter interface.
Original issue reported on code.google.com by [email protected]
on 25 Aug 2014 at 10:58
hello,
go9p is unsupported on Plan 9, as there is no sycall.Errno defined on Plan 9.
as a short term solution, i changed the definition to a uint, but it makes for
poor error messages and compatability.
is there any good way to have errors work on plan 9, where errors are strings,
and unix systems, where errors are generally numbers that are translated to
strings?
it is used here: https://code.google.com/p/go9p/source/browse/p/p9.go#118
i think it would be very nice if this worked out of the box on plan 9.
i'm using go version devel +d881cb1ffc14 Wed Aug 07 13:36:41 2013 +1000
plan9/386 on 9front.
Original issue reported on code.google.com by [email protected]
on 22 Aug 2013 at 4:54
What steps will reproduce the problem?
1. goinstall go9p.googlecode.com/hg/p/ #works fine
goinstall go9p.googlecode.com/hg/p/clnt
2. error:
goinstall: === cd
/home/johnny/dev/golang/src/pkg/go9p.googlecode.com/hg/p/clnt; gomake -f-
install
8g -o _go_.8
/home/johnny/dev/golang/src/pkg/go9p.googlecode.com/hg/p/clnt/clnt.go
/home/johnny/dev/golang/src/pkg/go9p.googlecode.com/hg/p/clnt/close.go
/home/johnny/dev/golang/src/pkg/go9p.googlecode.com/hg/p/clnt/write.go
/home/johnny/dev/golang/src/pkg/go9p.googlecode.com/hg/p/clnt/stat.go
/home/johnny/dev/golang/src/pkg/go9p.googlecode.com/hg/p/clnt/stats_http.go
/home/johnny/dev/golang/src/pkg/go9p.googlecode.com/hg/p/clnt/walk.go
/home/johnny/dev/golang/src/pkg/go9p.googlecode.com/hg/p/clnt/open.go
/home/johnny/dev/golang/src/pkg/go9p.googlecode.com/hg/p/clnt/read.go
/home/johnny/dev/golang/src/pkg/go9p.googlecode.com/hg/p/clnt/remove.go
/home/johnny/dev/golang/src/pkg/go9p.googlecode.com/hg/p/clnt/stats_none.go
/home/johnny/dev/golang/src/pkg/go9p.googlecode.com/hg/p/clnt/mount.go
/home/johnny/dev/golang/src/pkg/go9p.googlecode.com/hg/p/clnt/pool.go
/home/johnny/dev/golang/src/pkg/go9p.googlecode.com/hg/p/clnt/stats_none.go:3:
statsRegister redeclared in this block
previous declaration at /home/johnny/dev/golang/src/pkg/go9p.googlecode.com/hg/p/clnt/stats_http.go:10
/home/johnny/dev/golang/src/pkg/go9p.googlecode.com/hg/p/clnt/stats_none.go:6:
*Clnt·statsRegister redeclared in this block
previous declaration at /home/johnny/dev/golang/src/pkg/go9p.googlecode.com/hg/p/clnt/stats_http.go:29
/home/johnny/dev/golang/src/pkg/go9p.googlecode.com/hg/p/clnt/stats_none.go:9:
*Clnt·statsUnregister redeclared in this block
previous declaration at /home/johnny/dev/golang/src/pkg/go9p.googlecode.com/hg/p/clnt/stats_http.go:33
make: *** [_go_.8] Error 1
--- exit status 2
goinstall: installing go9p.googlecode.com/hg/p/clnt: running gomake: exit
status 2
3. same thing for p/srv
What is the expected output? What do you see instead?
Expected p/clnt and p/srv to install properly
What version of the product are you using? On what operating system?
latest mercurial revision of both golang and go9p
Original issue reported on code.google.com by [email protected]
on 24 Sep 2010 at 2:56
marko@ributtalo $ ./ls -addr="127.0.0.1:5645" /
2011/06/06 18:19:22 Error
(I use ufs.go as 9p server, and it works fine with 9mount on linux)
"ReadDir(0)" returns the error, and the error has an empty string message.
Original issue reported on code.google.com by [email protected]
on 6 Jun 2011 at 4:24
diff -r 620e384be698 p/fmt.go
--- a/p/fmt.go Tue Nov 16 11:13:34 2010 -0700
+++ b/p/fmt.go Thu Nov 18 15:06:10 2010 -0800
@@ -124,7 +124,7 @@
case Ropen:
ret = fmt.Sprintf("Ropen tag %d qid %v iounit %d", fc.Tag, &fc.Qid, fc.Iounit)
case Rcreate:
- ret = fmt.Sprintf("Rcreate tag %d qid %v iounit %d", fc.Tag, fc.Qid,
fc.Iounit)
+ ret = fmt.Sprintf("Rcreate tag %d qid %v iounit %d", fc.Tag, &fc.Qid,
fc.Iounit)
case Tcreate:
ret = fmt.Sprintf("Tcreate tag %d fid %d name '%s' perm ", fc.Tag, fc.Fid, fc.Name)
ret += permToString(fc.Perm)
Original issue reported on code.google.com by [email protected]
on 18 Nov 2010 at 11:07
Srv.attach uses Unamenum to determine if user lookup should be done by uid. if
left uninitialized in non-dotu mode, a user lookup will be done by uid for uid
0 in Srv.attach, when the lookup should be done by username.
the fix i believe would be to initialize fc.Unamenum to p.NOUID unconditionally.
diff -r fbcdb68b9c01 p/unpack.go
--- a/p/unpack.go Fri Aug 23 06:37:54 2013 -0600
+++ b/p/unpack.go Wed May 14 11:57:09 2014 -0700
@@ -106,12 +106,9 @@
goto szerror
}
- if dotu {
- if len(p) > 0 {
- fc.Unamenum, p = gint32(p)
- } else {
- fc.Unamenum = NOUID
- }
+ fc.Unamenum = NOUID
+ if dotu && len(p) > 0 {
+ fc.Unamenum, p = gint32(p)
}
case Rerror:
Original issue reported on code.google.com by [email protected]
on 14 May 2014 at 7:03
What steps will reproduce the problem?
1. Compile and start a 9p server listening on e. g. socket /tmp/xxx
2. mount -t 9p /tmp/xxx /mnt/ -o trans=unix,version=9p2000.u,uname=<any valid
user name>
What is the expected output? What do you see instead?
Mount does not succeed:
mount: wrong fs type, bad option, bad superblock on /tmp/xxx,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
Mount does succeed with protocol version 9p2000 (without .u)
What version of the product are you using? On what operating system?
Current repo of go9p, Linux 3.13.0-36-generic #63-Ubuntu SMP Wed Sep 3 21:30:07
UTC 2014 x86_64 x86_64 x86_64 GNU/Linux, go version go1.3.1 linux/amd64
Please provide any additional information below.
After fixing the issue 30 (p/osusers.go) [1], the following code in
p/srv/fcall.go stopped working (line 118, attach function):
if tc.Unamenum != p.NOUID || conn.Dotu {
user = srv.Upool.Uid2User(int(tc.Unamenum))
} else if tc.Uname != "" {
user = srv.Upool.Uname2User(tc.Uname)
}
and there also is identical code in the auth function.
When mounting a 9p server, Linux sends Tattach with valid username, but numeric
user ID is -1. The code above calls Uid2User with such username when dotu mode
is active, however the lookup will certainly fail. In non-dotu mode the "else
if" branch is followed, so user lookup is successful.
The proposed patch replaces this code with
if tc.Unamenum != p.NOUID || (conn.Dotu && tc.Unamenum != p.NOUID) {
user = srv.Upool.Uid2User(int(tc.Unamenum))
} else if tc.Uname != "" || (conn.Dotu && tc.Uname != "") {
user = srv.Upool.Uname2User(tc.Uname)
}
that is, if numeric UID is -1, lookup by name only will be attempted.
Thanks.
[1]
https://code.google.com/p/go9p/source/detail?r=30ef0eabe4137d115fcb3d9b9d84bc2e7
6a40c25
Original issue reported on code.google.com by [email protected]
on 27 Sep 2014 at 1:56
Attachments:
This diff enables ufs to correctly report setuid and setgid files.
fixes todo in source: /* TODO: setuid and setgid */
Original issue reported on code.google.com by [email protected]
on 26 Nov 2010 at 7:50
Attachments:
What steps will reproduce the problem?
1. goinstall go9p.googlecode.com/hg/p && goinstall go9p.googlecode.com/hg/p/srv
&& goinstall go9p.googlecode.com/hg/p/clnt
2. cd $GOROOT/src/pkg/go9p.googlecode.com/hg/p/srv/examples
3. make
What is the expected output? What do you see instead?
expected: compilation succeeds
actual result:
$ make
8g -o ufs.8 ufs.go
8l -o ufs ufs.8
8l: conflicting definitions for "http".URL
ufs.8: type "http".URL struct { Raw string; Scheme string; RawAuthority
string; RawUserinfo string; Host string; RawPath string; Path string;
OpaquePath bool; RawQuery string; Fragment string }
func (url *"http".URL) IsAbs () bool
func (base *"http".URL) ParseURL (ref string) (? *"http".URL, ? "os".Error)
func (base *"http".URL) ResolveReference (ref *"http".URL) *"http".URL
func (url *"http".URL) String () string
/home/johnny/dev/golang/pkg/linux_386/go9p.googlecode.com/hg/p/srv.a(_go_.8):
type "http".URL struct { Raw string; Scheme string; RawAuthority string;
RawUserinfo string; Host string; RawPath string; Path string; OpaquePath bool;
RawQuery string; Fragment string }
func (url *"http".URL) String () string
make: *** [ufs] Segmentation fault
make: *** Deleting file `ufs'
What version of the product are you using? On what operating system?
latest hg tip:
$ hg identify
99d3f81dd91e tip
Please provide any additional information below.
I noticed this when my project wouldn't compile:
http://github.com/soul9/go-ircfs , in this case I know it's the linker that
segfaults
Original issue reported on code.google.com by [email protected]
on 22 Jan 2011 at 4:03
I terminated a network connection to my 9p server mid-read (i.e. after the
request, prior to the response) and the code in Conn.recv() called FidDestroy()
on the fid that was involved in the read! Very inconvenient. I didn't even
get a clunk.
I'm not sure if the solution here is to wait for the ref-cnt to hit 0, or Clunk
the fid. I don't think a Clunk will do much good as it will be handled by a
separate goroutine than the Read, which would require that I implement the
synchronization that go9p probably should here.
Thoughts?
Original issue reported on code.google.com by [email protected]
on 17 Nov 2010 at 8:42
What steps will reproduce the problem?
# clonefs -addr :564 & # p/srv/examples/clonefs
# mkdir /mnt/clonefs
# mount -t 9p 127.0.0.1 /mnt/clonefs
# cd /mnt/clonefs
# cat clone
1#
# echo text >>1
# echo text >1
bash: 1: Operation not permitted
#
What is the expected output? What do you see instead?
Expected "echo text >1" to succeed.
What version of the product are you using? On what operating system?
$ hg tip
changeset: 106:2de9ef38f3b6
tag: tip
user: Andrey Mirtchovski <[email protected]>
date: Mon Apr 02 13:44:29 2012 -0600
summary: Hardcoded certificates have expired. Allow "insecure" connections
by skipping the verify step until
$ uname -a
Linux hostname 2.6.38-11-generic-pae #50-Ubuntu SMP Mon Sep 12 22:21:04 UTC
2011 i686 i686 i386 GNU/Linux
$
Please provide any additional information below.
I recently wrote a trivial fs following the example code in timefs and clonefs
and
noticed the above error. Perhaps it is not by design?
http://9fans.net/archive/?q=%279pserve+question%27&go=Grep
seems to be related (strace and clonefs -d output attached);
applying the below patch fixes the issue.
$ hg diff .
diff -r 2de9ef38f3b6 p/srv/examples/clonefs/clonefs.go
--- a/p/srv/examples/clonefs/clonefs.go Mon Apr 02 13:44:29 2012 -0600
+++ b/p/srv/examples/clonefs/clonefs.go Mon Apr 30 18:45:45 2012 +0530
@@ -73,6 +73,10 @@
return len(data), nil
}
+func (cl *ClFile) Wstat(fid *srv.FFid, dir *p.Dir) error {
+ return nil
+}
+
func (cl *ClFile) Remove(fid *srv.FFid) error {
log.Println("Remove")
return nil
$
Thanks for go9p and the nice examples!
Arvindh
Original issue reported on code.google.com by [email protected]
on 30 Apr 2012 at 2:00
Attachments:
srv/fcall.go
func (srv *Srv) read(req *Req)
if tc.Count+p.IOHDRSZ > req.Conn.Msize {
req.RespondError(Etoolarge)
}
There probably should be a return here.
Original issue reported on code.google.com by [email protected]
on 14 Sep 2010 at 6:36
Recently, I had been looking for a decent 9P2000 server implementation
(preferably in Go). Not surprising, I have found go9p project.
Unfortunately, the complete lack of the unit tests, made it impossible to use
this code in our production.
Filing this issue are a feature request. Feel free to close it, as it's too
broad in scope and cannot be easily addressed.
Original issue reported on code.google.com by [email protected]
on 21 Oct 2012 at 9:17
A recent change to Go compilers, "gc: diagnose unused labels"
(http://code.google.com/p/go/source/detail?r=570c3ce8), makes compilation of
srv/srv.go fail:
srv.go:323: label unknown defined and not used
After that label definition is removed, the package compiles again:
--- a/p/srv/srv.go
+++ b/p/srv/srv.go
@@ -320,7 +320,6 @@
switch req.Tc.Type {
default:
- unknown:
req.RespondError(&p.Error{"unknown message type", syscall.ENOSYS})
case p.Tversion:
Original issue reported on code.google.com by [email protected]
on 25 Mar 2011 at 9:31
file, _ = c.FOpen(flag.Arg(0), p.OREAD)
dst, _ := os.OpenFile("/tmp/test", os.O_RDWR | os.O_CREATE, 0666)
_, ioerr := io.Copy(dst, file)
if ioerr != nil {
fmt.Printf("Error %s\n", ioerr)
}
Outputs:
Error i/o count too large
I'm not sure, but I think the Msize limit should be handled transparently in
the client.
Original issue reported on code.google.com by [email protected]
on 6 Jun 2011 at 3:09
Hi, nice job.
I think that it wouuld be nice if the clnt api would implement the io.Reader
interface for File.
In particular I want to be able to use: ioutil.ReadAll(file)
The first thing I noticed is:
noce.go:36: cannot use file (type *clnt.File) as type io.Reader in function
argument:
*clnt.File does not implement io.Reader (wrong type for Read method)
have Read(buf []uint8) (int, *p.Error)
want Read(p []uint8) (n int, err os.Error)
I tried to fix the signatures:
-func (clnt *Clnt) Read(fid *Fid, offset uint64, count uint32) ([]byte,
*p.Error) {
+func (clnt *Clnt) Read(fid *Fid, offset uint64, count uint32) ([]byte,
os.Error) {
....
and it built fine. However at runtime the ioutil.ReadAll(file) didn't return.
I suspect that the is some difference w.r.t the io.Reader interface in way EOF
is signaled.
Original issue reported on code.google.com by [email protected]
on 31 May 2011 at 9:30
What steps will reproduce the problem?
1. compile examples under go9p/p/clnt/examples and
go9p/p/srv/examples
2. start go9p/p/srv/examples/timefs
3. start go9p/p/clnt/examples/cl
4. from "cl" prompt enter "cd"
What is the expected output? nothing, or change to default/root of the
attached filesystem
What do you see instead?
PC=0x20fb index 0<0>0
throw: string bounds
What version of the product are you using?
6g version 5099 release.2010-03-22 release
On what operating system?
Darwin dhcp-64-100-95-181.cisco.com 10.2.0 Darwin Kernel Version
10.2.0: Tue Nov 3 10:37:10 PST 2009; root:xnu-
1486.2.11~1/RELEASE_I386 i386
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 24 Mar 2010 at 9:04
1. Start a server (I tried with examples ufs.go)
2. Start client which reads a (big) file, like
file, err := c.FOpen(name, p.OREAD)
if err != nil {
return nil, os.NewError(err.String())
}
defer file.Close()
buf := make([]byte, 8192)
for {
fmt.Printf("reading chunk\n")
n, err := file.Read(buf)
if err != nil {
return nil, os.NewError(err.String())
}
if n == 0 {
break
}
dest.Write(buf[0:n])
}
3. Kill the server in the middle of the write
The reader will be stuck during read and never resume.
Original issue reported on code.google.com by [email protected]
on 31 May 2011 at 1:32
The code which unregisters the http handler:
func (srv *Srv) statsRegister() {
http.Handle("/go9p/srv/"+srv.Id, srv)
}
func (srv *Srv) statsUnregister() {
http.Handle("/go9p/srv/"+srv.Id, nil)
}
Breaks with weekly 2012-03-22:
panic: http: nil handler
goroutine 6 [running]:
net/http.(*ServeMux).Handle(0xf840059900, 0xf8400ac090, 0x22, 0x0, 0x0, ...)
/usr/lib/go/src/pkg/net/http/server.go:937 +0x101
net/http.Handle(0xf8400ac090, 0x100000022, 0x0, 0x0, 0x73667500000003, ...)
/usr/lib/go/src/pkg/net/http/server.go:962 +0x52
code.google.com/p/go9p/p/srv.(*Conn).statsUnregister(0xf8400c0000, 0x5c0798)
/home/marko/gocode/src/code.google.com/p/go9p/p/srv/stats_http.go:40 +0x89
code.google.com/p/go9p/p/srv.(*Conn).recv(0xf8400c0000, 0x0)
/home/marko/gocode/src/code.google.com/p/go9p/p/srv/conn.go:155 +0x4ce
created by code.google.com/p/go9p/p/srv.(*Srv).NewConn
/home/marko/gocode/src/code.google.com/p/go9p/p/srv/conn.go:42 +0x28f
Original issue reported on code.google.com by [email protected]
on 24 Mar 2012 at 5:36
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.