> > Yes, it may confuse the user. It may even confuse the kernel for
> > sticky directories(*). But basically it just works, and is very
> > simple.
> >
>
> In principal, Plan 9 file servers handle permission checking
> server-side, so we could likewise punt -- but it seemed a good idea to
> ha
On 9/3/05, Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > While FUSE doesn't handle it directly, doesn't it have to punt it to
> > its network file systems, how to the sshfs and what not handle this
> > sort of mapping?
>
> Sshfs handles it by not handling it. In this case it is neither
> possible
> While FUSE doesn't handle it directly, doesn't it have to punt it to
> its network file systems, how to the sshfs and what not handle this
> sort of mapping?
Sshfs handles it by not handling it. In this case it is neither
possible, nor needed to be able to correctly map the id space.
Yes, it m
On 9/3/05, Miklos Szeredi <[EMAIL PROTECTED]> wrote:
>
> > I agree that lots of people would like the functionality. I regret that
> > although it appears that v9fs could provide it,
>
> I think you are wrong there. You don't appreciate all the complexity
> FUSE _lacks_ by not being network tra
- number of language bindings: 7 (native: C, java, python, perl,
- C#, sh, TCL)
8 now, someone just sent a private mail about bindings for the Pliant
(never heard of it) language.
9 now (there is an ocaml binding, and if you dont know ocaml, shame
on you).
I would just like to ad
> > > The main sticking point with FUSE remains the permission tricks around
> > > fuse_allow_task(). AFAIK it remains the case that nobody has come up
> > with
> > > any better idea, so I'm inclined to merge the thing.
> >
> > Do you promise?
>
> I troll. What others think matters. But a
Miklos Szeredi <[EMAIL PROTECTED]> wrote:
>
> > The main sticking point with FUSE remains the permission tricks around
> > fuse_allow_task(). AFAIK it remains the case that nobody has come up with
> > any better idea, so I'm inclined to merge the thing.
>
> Do you promise?
I troll. What oth
> Haven't thought about it all much. Have spent most of my time in the last
> month admiring the contents of kernel bugzilla, and the ongoing attempts to
> increase them.
A penal system could be created, for example if someone is caught
introducing a bug, he will have to choose three additional r
On Fri, 2005-09-02 at 15:34 -0700, Andrew Morton wrote:
> Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> >
> > Hi Andrew!
> >
> > Do you plan to send FUSE to Linus for 2.6.14?
>
i use fuse too, and i like it, it works good, and its quite fast and
easy. it has given me no problems at all, i suggest
On Friday 02 September 2005 15:34, Andrew Morton wrote:
> Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > Hi Andrew!
> >
> > Do you plan to send FUSE to Linus for 2.6.14?
...
> I agree that lots of people would like the functionality. I regret that
> although it appears that v9fs could provide it, t
Miklos Szeredi <[EMAIL PROTECTED]> wrote:
>
> Hi Andrew!
>
> Do you plan to send FUSE to Linus for 2.6.14?
Haven't thought about it all much. Have spent most of my time in the last
month admiring the contents of kernel bugzilla, and the ongoing attempts to
increase them.
> I know you have some
Hi Andrew!
Do you plan to send FUSE to Linus for 2.6.14?
I know you have some doubts about usefulness, etc. Here are a couple
of facts, that I hope show that Linux should benefit from having FUSE:
- total number of downloads from SF: ~25000
- number of downloads of last release (during 3 mon
On Mon, Jul 04, 2005 at 03:17:35PM +0200, Miklos Szeredi wrote:
> > > I see your point. But then this is really not a security issue, but
> > > an "are you sure you want to format C:" style protection for the
> > > user's own sake. Adding a mount option (checked by the library) for
> > > this wou
> > I see your point. But then this is really not a security issue, but
> > an "are you sure you want to format C:" style protection for the
> > user's own sake. Adding a mount option (checked by the library) for
> > this would be fine. E.g. with "mount_nonempty" it would not refuse to
> > mount
Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> I see your point. But then this is really not a security issue, but
> an "are you sure you want to format C:" style protection for the
> user's own sake. Adding a mount option (checked by the library) for
> this would be fine. E.g. with "mount_nonempt
On Mon, Jul 04, 2005 at 12:27:13PM +0200, Miklos Szeredi wrote:
> E.g. with "mount_nonempty" it would not refuse to
> mount on a non-leaf dir, and README would document, that using this
> option might cause trouble. Otherwise the mount would be refused with
> a reference to the above option.
that
On 7/4/05, Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> Here are some numbers on the size these filesystems as in current -mm
> ('wc fs/${fs}/* include/linux/${fs}*')
Sloccount [1] gives more meaningful numbers than wc:
('sloccount fs/${fs}/* include/linux/${fs}*')
nfs: 21,046
9p:3,856
coda:
> "solving it properly" refers to hardening the leaf node constraint
> against circumvention I assume. Suppose there's a script for doing simple
> on-line backups using "find". Now explain to the user why he lost his
> data due to a backup script geting EACCES on a non-leaf FUSE mount.
I see your
On Mon, Jul 04, 2005 at 10:56:30AM +0200, Miklos Szeredi wrote:
> > It is important because on UNIX, "root" rules on local filesystems.
> > I dont't like the idea of root not being able to run "find -xdev"
> > anymore for administrative tasks, just because something got hidden
> > by accident or ju
[CC restored]
> Okay, I just wanted to mention CODA. Modifying CODA is probably still
> better than modifying NFS (as akpm suggested at one point).
Definitely.
Here are some numbers on the size these filesystems as in current -mm
('wc fs/${fs}/* include/linux/${fs}*')
nfs: 25495
9p:6102
co
> It is important because on UNIX, "root" rules on local filesystems.
> I dont't like the idea of root not being able to run "find -xdev"
> anymore for administrative tasks, just because something got hidden
> by accident or just for fun by a user. It's not about malicious
> users who want to hide
> Actually, the right question is "how is fuse better than coda". I've
> asked that before; unlike nfs, userspace filesystems implemented with
> coda actually *work*, but do not provide partial-file writes.
You answered your own question.
I did talk to Jan Harkes about the file I/O issue before s
22 matches
Mail list logo
