> Would you care to share?
Sure. But beware it's just a quick hack.
diff -r 92a579c6549c src/cmd/9pfuse/main.c
--- a/src/cmd/9pfuse/main.c Mon Dec 12 16:44:50 2011 -0500
+++ b/src/cmd/9pfuse/main.c Mon Jan 02 19:00:00 2012 +0100
@@ -837,6 +837,8 @@
void
fusereadlink(FuseMsg *m)
{
+
David du Colombier <0in...@gmail.com> writes:
> OK, I found the problem. At least concerning 9pfuse and symlink.
OK, great. So I'm not going crazy, after all. ;)
> I've something that work, but it's ugly.
Would you care to share?
> As supposed, other Unix special files don't seem to be curre
> When I use 9pfuse to mount the file system, I get a little further:
>
> lrw-rw 1 root root6 Mar 10 2005 video ->
> -rw-rw 1 root root3 Mar 10 2005 video10
>
> The symbolic links show up as links, but with the null string ("") as
> target. The Linux kernel interperets
> OK, I'm stumped. Maybe I'm making this more complicated than it has
> to be. Posing my question as simply as possible: If plan9port's vac
> is used to archive a Linux file system to venti, is there any way to
> access that file system in a way that exposes symbolic links, device
> nodes, socket
OK, I'm stumped. Maybe I'm making this more complicated than it has to
be. Posing my question as simply as possible: If plan9port's vac is
used to archive a Linux file system to venti, is there any way to access
that file system in a way that exposes symbolic links, device nodes,
sockets, and FIF
> Who decided that .u is deprecated? I definitely didn't and I am using
> it for all my file servers that are supposed to work on Unix.
Sorry, I mean the plan9port support for 9p2000.u is deprecated.
It was removed in december 2010.
--
David du Colombier
On Wed, Dec 28, 2011 at 4:48 PM, David du Colombier <0in...@gmail.com> wrote:
> Forget about 9p2000.u, it's deprecated.
Who decided that .u is deprecated? I definitely didn't and I am using
it for all my file servers that are supposed to work on Unix.
Thanks,
Lucho
> IIRC, the RFC for it didn't indicate deprecated status. (Perhaps IETF
> could use an update.) Assuming it has been deprecated, with what has
> 9p2000.u been replaced?
As far I know, these RFCs were early draft and were never completed
nor submitted.
I think the 9P2000.u authors moved to a new
David du Colombier <0in...@gmail.com> writes:
> The problem you are encountering is that v9fs doesn't translate
> uid/gid strings back to their numeric equivalent in /etc/passwd.
> Since Unix doesn't know how to handle these strings, it falls
> back to -1.
I had suspected that. However, the uid/
> When I mount the file system, all the files are owned by uid = gid =
> (-2 mod 2^32), unless I tell the Linux kernel to mount the fs as a
> specific user/group. In the latter case, all files present with the
> specified user/group (as expected). I can't find any way to get at
> the actual uid/g
Hello,
I'm trying to use vac/vacfs on p9p, using the Linux v9fs driver (-t 9p)
with unix domain sockets as transport (-o trans=unix). And I'm
confused. :(
When I mount the file system, all the files are owned by uid = gid = (-2
mod 2^32), unless I tell the Linux kernel to mount the fs as a spec
Fixed in http://code.swtch.com/plan9port/changeset/c9f799b3ad09/
Thanks.
>
> Also, has anyone ever been able to debug p9p apps with gdb? I try to
> set breakpoints, but the apps just blow right through them, I'm not
> sure why... if not, is there any other answer for debugging p9p apps?
>
For starters try setting:
(gdb) set follow-fork-mode child
before running the p
I believe that the bug that people have been having with vac and venti
in p9p (create bsize 8192 psize 8160vac: vacfscreate: vacfileroot:
read too small: asked for 0 need at least 389) can be fixed by this
change:
(in plan9port/src/libventi/fcall.c:185), change "f->count = (buf[2] <<
8) | buf[3];"
On Tue, Jun 23, 2009 at 12:50 AM, erik quanstrom wrote:
>> looks like it's related to the error above. you might want to downgrade to
>> http://swtch.com/plan9port/plan9port-20090609.tgz
>
> fortune tells me
>
> The most effective debugging tool is still careful thought,
> coupled with judiciously
> looks like it's related to the error above. you might want to downgrade to
> http://swtch.com/plan9port/plan9port-20090609.tgz
fortune tells me
The most effective debugging tool is still careful thought,
coupled with judiciously placed print statements.
-Kernighan, 1978
i don't think t
if you want.
>>
>> Mathieu
>>
>>
>> -- Forwarded message --
>> From: Adrian Tritschler
>> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
>> Date: Mon, 22 Jun 2009 21:33:22 +1000
>> Subject: Re: [9fans] p9p vac issue
>&
---
> From: Adrian Tritschler
> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
> Date: Mon, 22 Jun 2009 21:33:22 +1000
> Subject: Re: [9fans] p9p vac issue
> 2009/6/22 Mathieu L.
>>
>> Indeed, this works for me as well.
>
>
>>
>> I&#x
if you can't get an old one from swtch.com, I can tar this mid-february
tree I have - or rather only the necessary parts - and serve it to you
if you want.
Mathieu
--- Begin Message ---
2009/6/22 Mathieu L.
> Indeed, this works for me as well.
> I've just migrated the arenas, bloom and isect
OK, so all I need now is to get my hands on an old copy of the p9p
binaries... the only old ones I've got are carefully backed up
inside the venti that I can't get at :)
I'm not sure why you may need binaries as you say, but older source
revs can be pulled from hg or cvs, also giving a ch
2009/6/22 Mathieu L.
> Indeed, this works for me as well.
> I've just migrated the arenas, bloom and isect to another machine with
> a p9p tree from mid February and I had no problem unvacing my data
> there. And for what it's worth, checkindex on that machine didn't report
> any problem while
Indeed, this works for me as well.
I've just migrated the arenas, bloom and isect to another machine with
a p9p tree from mid February and I had no problem unvacing my data
there. And for what it's worth, checkindex on that machine didn't report
any problem while it did on the machine with the rece
X-No-Archive: Yes
This is not much of a solution to the problem,
however I have temporarily resolved my issue
by performing vac/unvac using my p9p tree
from mid-March, and then resorting to the
latest p9p for vacfs/9pfuse in order to mount
my archives.
For those researching the issue, I
X-No-Archive: Yes
Adrian T. wrote:> There were a few followups with a subject of> "p9p venti
problem", but no fix.
I had looked up that thread, and the thread that Venkatesh S.refers to earlier
with the subject "P9P venti/copy bug?" from9fans:2009/02:198. Nathaniel F.
suggests a patch in 9fans:
Same problem that I've had since about the 10th of June on two
separate p9p ventis on two machines, I can no longer get data into
them or out of them. There were a few followups with a subject of
"p9p venti problem", but no fix. If you get a solution please let me
know what it is.
thanks
A
X-No-Archive: YesI'm using the latest p9p and the following fails for a simple
directory A containing a file a with the text Aa:vac -h localhost -v -f A.vac
AThe error is:create bsize 8192 psize 8160vac: vacfscreate: vacfileroot: read
too small: asked for 0 need at least 389The archive is a fre
the vac -m bug is fixed.
(it was fixed earlier tonight, i just
forgot to push the fix to cvs.)
if you use vac -m to manage
a dump-like tree of backups,
you will likely be interested in
the new -a flag, which automates
the process.
also, -e takes glob patterns now,
and -x will read patterns from
Sorry Russ, I just updated again from CVS and rebuilt p9p, but the
problem remains.
P.S.
I still keep an older version of p9p which works as far as "vac -m" is
concerned.
Myron
Russ Cox wrote:
I recently updated my p9p from the CVS respository, and vac fails when I try
to use the -m option
> I recently updated my p9p from the CVS respository, and vac fails when I try
> to use the -m option for merging. I am not sure whether the cause of the
> problem is in venti or in vac.
I did not test that well enough.
It should be fixed now.
Russ
Dear 9fans,
I recently updated my p9p from the CVS respository, and vac fails when I try
to use the -m option for merging. I am not sure whether the cause of the
problem is in venti or in vac.
Here is a transcript of what I did:
vac -f main.vac -m main
vac: could not walk main in main/2008-05-0
30 matches
Mail list logo
