.fr> wrote:
> Eric Van Hensbergen wrote on Mon, Apr 13, 2015 at 04:05:28PM +:
> > Well, technically fid 3 isn't 'open', only fid 2 is open - at least
> > according to the protocol. fid 3 and fid 2 are both clones of fid 1.
>
> Right, they're clone fid
That patch looks fine by me. Happy to put it in the queue. Thanks Al.
On Tue, Apr 14, 2015 at 11:07 AM Al Viro wrote:
> On Mon, Apr 13, 2015 at 04:05:28PM +0000, Eric Van Hensbergen wrote:
> > Well, technically fid 3 isn't 'open', only fid 2 is open - at least
>
Well, technically fid 3 isn't 'open', only fid 2 is open - at least
according to the protocol. fid 3 and fid 2 are both clones of fid 1.
However, thanks for the alternative workaround. If you get a chance, can
you check that my change to the client to partially fix this for the other
servers does
On Sun, Apr 12, 2015 at 9:09 AM, Al Viro wrote:
> On Sun, Apr 12, 2015 at 12:42:35PM -0000, Eric Van Hensbergen wrote:
>
> > In other words, it only uses the open fd to derrive a path and then
> > executes the getattr off of that path. If that path no longer exists
> &g
** Bug watch added: Red Hat Bugzilla #1114221
https://bugzilla.redhat.com/show_bug.cgi?id=1114221
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1336794
Title:
9pfs does not honor open file handl
I've done some digging from the client side. As is mentioned in Miklos'
original patch (which appears to have been shot down) the higher level
implementation appear to be broken for this. Here's what the code looks
like for fstat in fs/stat.c:
int vfs_fstat(unsigned int fd, struct kstat *stat)
{
Yeah, that's probably overdue -- it should gracefully downgrade to 9p2000.u
and/or 9p2000 anyways.
-eric
On Fri, Mar 1, 2013 at 1:38 PM, H. Peter Anvin wrote:
> On 02/28/2013 04:24 AM, M. Mohan Kumar wrote:
> >
> > By default 9p.u is used, you can override by that
> > mount -t 9p -otrans=
On Mon, Oct 15, 2012 at 6:36 AM, Chris Webb wrote:
>
> Whilst we can mount the shares on each host and then use qemu's 9p
> passthrough/proxy support to access the mountpoint, going via the host
> kernel and vfs like this feels quite inefficient. We would be converting
> back and forth between vfs
On Sun, Apr 24, 2011 at 2:31 PM, Rob Landley wrote:
> So on the host side I'm trying to do this:
>
> $ qemu -cpu pentium3 -nographic -no-reboot -kernel bzImage \
> -hda hda.sqf -append 'root=/dev/hda rw init=/sbin/init.sh panic=1 \
> PATH=/bin:/sbin console=ttyS0 HOST=i686 ' -net nic,model=e1000
