Module Name:src
Committed By: andvar
Date: Sat Mar 30 22:05:07 UTC 2024
Modified Files:
src/lib/libperfuse: perfuse.c
Log Message:
s/Unfortunatley/Unfortunately/ in comment.
To generate a diff of this commit:
cvs rdiff -u -r1.44 -r1.45 src/lib/libperfuse/perfuse.c
Pleas
Module Name:src
Committed By: andvar
Date: Sat Mar 30 22:05:07 UTC 2024
Modified Files:
src/lib/libperfuse: perfuse.c
Log Message:
s/Unfortunatley/Unfortunately/ in comment.
To generate a diff of this commit:
cvs rdiff -u -r1.44 -r1.45 src/lib/libperfuse/perfuse.c
Pleas
Module Name:src
Committed By: uwe
Date: Sun Sep 8 11:34:56 UTC 2019
Modified Files:
src/lib/libperfuse: libperfuse.3
Log Message:
Use the right values for .Bl -width
Typeset "fuse" literal (default value for type) as a literal.
To generate a diff of this commit:
cvs rdi
Module Name:src
Committed By: uwe
Date: Sun Sep 8 11:34:56 UTC 2019
Modified Files:
src/lib/libperfuse: libperfuse.3
Log Message:
Use the right values for .Bl -width
Typeset "fuse" literal (default value for type) as a literal.
To generate a diff of this commit:
cvs rdi
Module Name:src
Committed By: manu
Date: Sat Aug 10 07:08:12 UTC 2019
Modified Files:
src/lib/libperfuse: ops.c
Log Message:
Rollback directory filehandle screening for FUSE lock operations
libfuse has a different usage of filehandles for files and directories.
A director
Module Name:src
Committed By: manu
Date: Sat Aug 10 07:08:12 UTC 2019
Modified Files:
src/lib/libperfuse: ops.c
Log Message:
Rollback directory filehandle screening for FUSE lock operations
libfuse has a different usage of filehandles for files and directories.
A director
David Holland wrote:
> If you're sure that all the cases match ffs (which we believe to be
> correct on this stuff, modulo any kauth glitches) then I have no
> objection. It's just that most fs-level permission failures are
> supposed to be EACCES so I was alarmed.
>
> > Please Cc: me for the r
On Fri, Sep 05, 2014 at 01:57:19PM +, Emmanuel Dreyfus wrote:
> > > Modified Files:
> > > src/lib/libperfuse: ops.c perfuse.c
> > >
> > > Log Message:
> > > Improve POSIX compliance of FUSE filesystems through PERUSE
> > > - access denied is EPERM and not EACCES
> >
> > wai
On Date: Wed, 3 Sep 2014 18:43:34 +, David Holland wrote:
> On Wed, Sep 03, 2014 at 04:01:45PM +, Emmanuel Dreyfus wrote:
> > Modified Files:
> > src/lib/libperfuse: ops.c perfuse.c
> >
> > Log Message:
> > Improve POSIX compliance of FUSE filesystems through PERUSE
> > - access
On Wed, Sep 03, 2014 at 04:01:45PM +, Emmanuel Dreyfus wrote:
> Modified Files:
> src/lib/libperfuse: ops.c perfuse.c
>
> Log Message:
> Improve POSIX compliance of FUSE filesystems through PERUSE
> - access denied is EPERM and not EACCES
wait, what?
--
David A. Holland
dholl...@
In article <20111229042549.daefb17...@cvs.netbsd.org>,
Jeff Rizzo wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: riz
>Date: Thu Dec 29 04:25:49 UTC 2011
>
>Modified Files:
> src/lib/libperfuse: debug.c
>
>Log Message:
>Redo previous; remove all the casts I added, and use
> On Dec 28, 2011, at 8:40 PM, matthew green wrote:
> > - time_t can be a floating point type
>
> For my information, have there ever been any systems that represent time_t as
> a float?
it's been a while. i see this reference off hand:
http://lua-users.org/lists/lua-l/2006-01/msg00148
On Dec 28, 2011, at 8:40 PM, matthew green wrote:
> - time_t can be a floating point type
For my information, have there ever been any systems that represent time_t as a
float?
Warner
In article <20111229014033.2f33917...@cvs.netbsd.org> you write:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: riz
>Date: Thu Dec 29 01:40:32 UTC 2011
>
>Modified Files:
> src/lib/libperfuse: debug.c
>
>Log Message:
>Cast time_t to intmax_t for printf purposes, and format wit
> On 12/28/11 5:57 PM, Alistair Crooks wrote:
> > On Thu, Dec 29, 2011 at 01:40:33AM +, Jeff Rizzo wrote:
> >> Module Name: src
> >> Committed By: riz
> >> Date: Thu Dec 29 01:40:32 UTC 2011
> >>
> >> Modified Files:
> >>src/lib/libperfuse: debug.c
> >>
> >> Log Mes
On 12/28/11 5:57 PM, Alistair Crooks wrote:
On Thu, Dec 29, 2011 at 01:40:33AM +, Jeff Rizzo wrote:
Module Name:src
Committed By: riz
Date: Thu Dec 29 01:40:32 UTC 2011
Modified Files:
src/lib/libperfuse: debug.c
Log Message:
Cast time_t to intmax_t for printf purpo
On Thu, Dec 29, 2011 at 01:40:33AM +, Jeff Rizzo wrote:
> Module Name: src
> Committed By: riz
> Date: Thu Dec 29 01:40:32 UTC 2011
>
> Modified Files:
> src/lib/libperfuse: debug.c
>
> Log Message:
> Cast time_t to intmax_t for printf purposes, and format with %j. Fixes
> bui
On Sun, Oct 23, 2011 at 05:13:13PM +1100, matthew green wrote:
...
> > perfuse memory usage can grow quite large when using a lot of vnodes,
> > and the amount of data memory involved is not easy to forcast. We therefore
> > raise the limit to the maximum.
...
> this seems like the wrong answer. i
On Sun, Oct 23, 2011 at 08:42:35PM +1100, matthew green wrote:
>
> > matthew green wrote:
> >
> > > this seems like the wrong answer. if rlimits aren't enough, then the
> > > *user* should be increasing them, not the system.
> >
> > The problem is that we have no way to pass that as a mount op
> none of this is any good reason to overrride the users rlimit.
> the perfuse code should maintain a cache that keeps under the
> users data rlimit.
>
> this change should be reverted.
... and the documentation should be changed to say that until perfuse
is fixed to not use unlimited memory, us
> matthew green wrote:
>
> > this seems like the wrong answer. if rlimits aren't enough, then the
> > *user* should be increasing them, not the system.
>
> The problem is that we have no way to pass that as a mount option, and
> no way to evaluate how much memory will b e required.
a cache sh
matthew green wrote:
> this seems like the wrong answer. if rlimits aren't enough, then the
> *user* should be increasing them, not the system.
The problem is that we have no way to pass that as a mount option, and
no way to evaluate how much memory will b e required.
> additionally, why does
> Module Name: src
> Committed By: manu
> Date: Sun Oct 23 05:01:00 UTC 2011
>
> Modified Files:
> src/lib/libperfuse: perfuse.c
>
> Log Message:
> perfuse memory usage can grow quite large when using a lot of vnodes,
> and the amount of data memory involved is not easy to forcast
On Sep 10, 8:31am, kar...@netbsd.org (Frank Kardel) wrote:
-- Subject: Re: CVS commit: src/lib/libperfuse
| Hi Christos,
|
| I think that didn't quite work the tree from this morning gives me this:
| lcc1: warnings being treated as errors
| /fs/raid1a/src/NetBSD/cur/src/lib/libperfuse/
Hi Christos,
I think that didn't quite work the tree from this morning gives me this:
lcc1: warnings being treated as errors
/fs/raid1a/src/NetBSD/cur/src/lib/libperfuse/ops.c: In function
'perfuse_node_read':
/fs/raid1a/src/NetBSD/cur/src/lib/libperfuse/ops.c:2838:22: error:
comparison betwee
On Wed, 29 Jun 2011, Christos Zoulas wrote:
Emmanuel Dreyfus wrote:
LIB=perfuse
-LIBDPLIBS+= puffs ${.CURDIR}/../libpuffs
+LIBDPLIBS+= puffs /usr/src/lib/libpuffs
Looks wrong.
If ${.CURDIR} doesn't do the right thing, then perhaps you want
${.PARSEDIR}.
--apb (Alan
In article <20110628161917.8fcca17...@cvs.netbsd.org>,
Emmanuel Dreyfus wrote:
> LIB=perfuse
>-LIBDPLIBS+= puffs ${.CURDIR}/../libpuffs
>+LIBDPLIBS+= puffs /usr/src/lib/libpuffs
Looks wrong.
>
>-.ifdef DEBUG
> PERFUSE_OPT_DEBUG_FLAGS= -g -DPERFUSE_DEBUG
>-.endif
christos
On Thu Aug 26 2010 at 13:07:14 +, Emmanuel Dreyfus wrote:
> On Thu, Aug 26, 2010 at 04:01:38PM +0300, Antti Kantee wrote:
> > IIRC ntfs-3g has been shipped with its own hacked copy of libfuse for
> > quite some time now. So technically ntfs-3g uses the kernel interface
> > as well. (but I nev
On Thu, Aug 26, 2010 at 04:01:38PM +0300, Antti Kantee wrote:
> IIRC ntfs-3g has been shipped with its own hacked copy of libfuse for
> quite some time now. So technically ntfs-3g uses the kernel interface
> as well. (but I never looked at the code, so I don't know if it's
> optional or what give
On Thu Aug 26 2010 at 05:51:59 +0200, Emmanuel Dreyfus wrote:
> The confusion was expected, as we now have two high level FUSE API. Here
> is a little sketch that may be worth a long explanation
>
> FUSE filesystemsmore FUSE filesystems
> ^
Lubomir Sedlacik wrote:
> > There is "per" instead of "re" in the name :-)
> Perhaps "con" would've been more appropriate, given the reactions. :)
You will have to find a meaning for that one!
The confusion was expected, as we now have two high level FUSE API. Here
is a little sketch that may
On Thu, Aug 26, 2010 at 03:39:04AM +0200, Emmanuel Dreyfus wrote:
> Matthias Scheler wrote:
> > Can you please explain what is the difference between "libperfuse"
> > and "librefuse" is?
>
> There is "per" instead of "re" in the name :-)
Perhaps "con" would've been more appropriate, given the re
Matthias Scheler wrote:
> Can you please explain what is the difference between "libperfuse" and
> "librefuse" is?
There is "per" instead of "re" in the name :-)
Here is the explanation:
http://mail-index.netbsd.org/tech-userlevel/2010/08/22/msg003843.html
--
Emmanuel Dreyfus
http://hcpnet.fr
On 25 Aug 2010, at 8:16, Emmanuel Dreyfus wrote:
> Log Message:
> libperfuse(3) is a PUFFS relay to FUSE. In order to use it,
> FUSE filesystem must be patched to #include in the source
> files that open /dev/fuse and perform the mount(2) system call. The
> FUSE filesystem must be linked with -lp
34 matches
Mail list logo
