<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.comp.file-systems.fuse.devel">
    <title>gmane.comp.file-systems.fuse.devel</title>
    <link>http://blog.gmane.org/gmane.comp.file-systems.fuse.devel</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11557"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11556"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11555"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11554"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11553"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11552"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11551"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11550"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11549"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11548"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11547"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11546"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11545"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11544"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11543"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11542"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11541"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11540"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11539"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11538"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11557">
    <title>modified hello_ll: setattr error</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11557</link>
    <description>&lt;pre&gt;Hello.

I have modified the example. I have added hello_ll_setattr and
hello_ll_release. It's not read-only now.

$./hello_ll fs -d
$t$ touch fs/hello
touch: closing `fs/hello': Input/output error

Log:
...
unique: 114, opcode: OPEN (14), nodeid: 2, insize: 48
   unique: 114, success, outsize: 32
unique: 115, opcode: FLUSH (25), nodeid: 2, insize: 64
   unique: 115, error: -38 (Function not implemented), outsize: 16
unique: 116, opcode: SETATTR (4), nodeid: 2, insize: 128
   unique: 116, success, outsize: 120
unique: 117, opcode: RELEASE (18), nodeid: 2, insize: 64
   unique: 117, success, outsize: 16
...

Why It doesn't work?


/*
  FUSE: Filesystem in Userspace
  Copyright (C) 2001-2007  Miklos Szeredi &amp;lt;miklos-sUDqSbJrdHQHWmgEVkV9KA&amp;lt; at &amp;gt;public.gmane.org&amp;gt;

  This program can be distributed under the terms of the GNU GPL.
  See the file COPYING.

  gcc -Wall `pkg-config fuse --cflags --libs` hello_ll.c -o hello_ll
*/

#define FUSE_USE_VERSION 26

#include &amp;lt;fuse_lowlevel.h&amp;gt;
#include &amp;lt;stdio.h&amp;gt;
#include &amp;lt;stdlib.h&amp;gt;
#include &amp;lt;string.h&amp;gt;
#include &amp;lt;errno.h&amp;gt;
#include &amp;lt;fcntl.h&amp;gt;
#include &amp;lt;unistd.h&amp;gt;
#include &amp;lt;assert.h&amp;gt;

static const char *hello_str = "Hello World!\n";
static const char *hello_name = "hello";

static int hello_stat(fuse_ino_t ino, struct stat *stbuf)
{
stbuf-&amp;gt;st_ino = ino;
switch (ino) {
case 1:
stbuf-&amp;gt;st_mode = S_IFDIR | 0755;
stbuf-&amp;gt;st_nlink = 2;
stbuf-&amp;gt;st_uid = 1000;
stbuf-&amp;gt;st_gid = 1000;
break;

case 2:
stbuf-&amp;gt;st_mode = S_IFREG | 0644;
stbuf-&amp;gt;st_nlink = 1;
stbuf-&amp;gt;st_size = strlen(hello_str);
stbuf-&amp;gt;st_uid = 1000;
stbuf-&amp;gt;st_gid = 1000;
break;

default:
return -1;
}
return 0;
}

static void hello_ll_getattr(fuse_req_t req, fuse_ino_t ino,
     struct fuse_file_info *fi)
{
struct stat stbuf;

(void) fi;

memset(&amp;amp;stbuf, 0, sizeof(stbuf));
if (hello_stat(ino, &amp;amp;stbuf) == -1)
fuse_reply_err(req, ENOENT);
else
fuse_reply_attr(req, &amp;amp;stbuf, 1.0);
}

static void hello_ll_setattr(fuse_req_t req, fuse_ino_t ino, struct
stat *attr, int to_set, struct fuse_file_info *fi) {
fuse_reply_attr(req, attr, 300);
}

static void hello_ll_lookup(fuse_req_t req, fuse_ino_t parent, const char *name)
{
struct fuse_entry_param e;

if (parent != 1 || strcmp(name, hello_name) != 0)
fuse_reply_err(req, ENOENT);
else {
memset(&amp;amp;e, 0, sizeof(e));
e.ino = 2;
e.attr_timeout = 1.0;
e.entry_timeout = 1.0;
hello_stat(e.ino, &amp;amp;e.attr);

fuse_reply_entry(req, &amp;amp;e);
}
}

struct dirbuf {
char *p;
size_t size;
};

static void dirbuf_add(fuse_req_t req, struct dirbuf *b, const char *name,
       fuse_ino_t ino)
{
struct stat stbuf;
size_t oldsize = b-&amp;gt;size;
b-&amp;gt;size += fuse_add_direntry(req, NULL, 0, name, NULL, 0);
b-&amp;gt;p = (char *) realloc(b-&amp;gt;p, b-&amp;gt;size);
memset(&amp;amp;stbuf, 0, sizeof(stbuf));
stbuf.st_ino = ino;
fuse_add_direntry(req, b-&amp;gt;p + oldsize, b-&amp;gt;size - oldsize, name, &amp;amp;stbuf,
  b-&amp;gt;size);
}

#define min(x, y) ((x) &amp;lt; (y) ? (x) : (y))

static int reply_buf_limited(fuse_req_t req, const char *buf, size_t bufsize,
     off_t off, size_t maxsize)
{
if (off &amp;lt; bufsize)
return fuse_reply_buf(req, buf + off,
      min(bufsize - off, maxsize));
else
return fuse_reply_buf(req, NULL, 0);
}

static void hello_ll_readdir(fuse_req_t req, fuse_ino_t ino, size_t size,
     off_t off, struct fuse_file_info *fi)
{
(void) fi;

if (ino != 1)
fuse_reply_err(req, ENOTDIR);
else {
struct dirbuf b;

memset(&amp;amp;b, 0, sizeof(b));
dirbuf_add(req, &amp;amp;b, ".", 1);
dirbuf_add(req, &amp;amp;b, "..", 1);
dirbuf_add(req, &amp;amp;b, hello_name, 2);
reply_buf_limited(req, b.p, b.size, off, size);
free(b.p);
}
}

static void hello_ll_open(fuse_req_t req, fuse_ino_t ino,
  struct fuse_file_info *fi)
{
if (ino != 2)
fuse_reply_err(req, EISDIR);
//else if ((fi-&amp;gt;flags &amp;amp; 3) != O_RDONLY)
//fuse_reply_err(req, EACCES);
else
fuse_reply_open(req, fi);
}

static void hello_ll_read(fuse_req_t req, fuse_ino_t ino, size_t size,
  off_t off, struct fuse_file_info *fi)
{
(void) fi;

assert(ino == 2);
reply_buf_limited(req, hello_str, strlen(hello_str), off, size);
}

static void hello_ll_release(fuse_req_t req, fuse_ino_t ino, struct
fuse_file_info *fi) {
fuse_reply_err(req, 0);
}

static struct fuse_lowlevel_ops hello_ll_oper = {
.lookup= hello_ll_lookup,
.getattr= hello_ll_getattr,
.setattr= hello_ll_setattr,
.readdir= hello_ll_readdir,
.open= hello_ll_open,
.read= hello_ll_read,
.release= hello_ll_release,
};

int main(int argc, char *argv[])
{
struct fuse_args args = FUSE_ARGS_INIT(argc, argv);
struct fuse_chan *ch;
char *mountpoint;
int err = -1;

if (fuse_parse_cmdline(&amp;amp;args, &amp;amp;mountpoint, NULL, NULL) != -1 &amp;amp;&amp;amp;
    (ch = fuse_mount(mountpoint, &amp;amp;args)) != NULL) {
struct fuse_session *se;

se = fuse_lowlevel_new(&amp;amp;args, &amp;amp;hello_ll_oper,
       sizeof(hello_ll_oper), NULL);
if (se != NULL) {
if (fuse_set_signal_handlers(se) != -1) {
fuse_session_add_chan(se, ch);
err = fuse_session_loop(se);
fuse_remove_signal_handlers(se);
fuse_session_remove_chan(ch);
}
fuse_session_destroy(se);
}
fuse_unmount(mountpoint, ch);
}
fuse_opt_free_args(&amp;amp;args);

return err ? 1 : 0;
}

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
&lt;/pre&gt;</description>
    <dc:creator>Андрей Гаврилин</dc:creator>
    <dc:date>2012-05-24T06:18:55</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11556">
    <title>Re: Current state of the art with inotify-likefunctionality?</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11556</link>
    <description>&lt;pre&gt;2012/5/23 JT Olds &amp;lt;jtolds-aCMSg5yP+xoAvxtiuMwx3w&amp;lt; at &amp;gt;public.gmane.org&amp;gt;:

How does your fs knows what has changed??

Stef

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
&lt;/pre&gt;</description>
    <dc:creator>Stef Bon</dc:creator>
    <dc:date>2012-05-23T20:40:59</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11555">
    <title>Re: Need to know user for implementing network filesystemsecurity</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11555</link>
    <description>&lt;pre&gt;Hi Sergey

fuse_get_context() -&amp;gt; uid &amp;amp; gid

getpwuid(uid) and getgrnam(gid) may help too.

Kevin
________________________________________
From: Sergey Cherepanov [scherepanov-3jdQX4nv5R1Wk0Htik3J/w&amp;lt; at &amp;gt;public.gmane.org]
Sent: Wednesday, May 23, 2012 10:49 AM
To: 'fuse-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f&amp;lt; at &amp;gt;public.gmane.org'
Subject: [fuse-devel] Need to know user for implementing network filesystem     security

Hi,

We wrote driver for network filesystem using fuse. It works just fine.
I have problem implementing security around access to files on this network filesystem through fuse driver.
This specific filesystem have ACL for each file, not translatable into user:group permission model on linux.
Filesystem will check user permission when opening file, stat file or ls dir. Problem that I do not know what actual user issued request to fuse, this information is not provided.
We are mounting fuse filesystem as root with -o allow_other option, which allow for everybody on box to access fuse mount. It makes fuse look like regular filesystem.
But to implement security, I need to know what user made call to fuse, and pass this information to network filesystem.

Question - is there any way to find who is actual user performing a call?

This problem did not exist originally in fuse, as it was designed to be run as user itself. But as soon as it is possible to share fuse mount with other users, security implementation come forward.

Did anybody thought how it can be handled? Should it require change of fuse API?

Thank you
Sergey

________________________________

This e-mail and its attachments are intended only for the individual or entity to whom it is addressed and may contain information that is confidential, privileged, inside information, or subject to other restrictions on use or disclosure. Any unauthorized use, dissemination or copying of this transmission or the information in it is prohibited and may be unlawful. If you have received this transmission in error, please notify the sender immediately by return e-mail, and permanently delete or destroy this e-mail, any attachments, and all copies (digital or paper). Unless expressly stated in this e-mail, nothing in this message should be construed as a digital or electronic signature.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
fuse-devel mailing list
fuse-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f&amp;lt; at &amp;gt;public.gmane.org
https://lists.sourceforge.net/lists/listinfo/fuse-devel

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
&lt;/pre&gt;</description>
    <dc:creator>Fox, Kevin M</dc:creator>
    <dc:date>2012-05-23T19:40:41</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11554">
    <title>Need to know user for implementing network filesystemsecurity</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11554</link>
    <description>&lt;pre&gt;Hi,

We wrote driver for network filesystem using fuse. It works just fine.
I have problem implementing security around access to files on this network filesystem through fuse driver.
This specific filesystem have ACL for each file, not translatable into user:group permission model on linux.
Filesystem will check user permission when opening file, stat file or ls dir. Problem that I do not know what actual user issued request to fuse, this information is not provided.
We are mounting fuse filesystem as root with -o allow_other option, which allow for everybody on box to access fuse mount. It makes fuse look like regular filesystem.
But to implement security, I need to know what user made call to fuse, and pass this information to network filesystem.

Question - is there any way to find who is actual user performing a call?

This problem did not exist originally in fuse, as it was designed to be run as user itself. But as soon as it is possible to share fuse mount with other users, security implementation come forward.

Did anybody thought how it can be handled? Should it require change of fuse API?

Thank you
Sergey

________________________________

This e-mail and its attachments are intended only for the individual or entity to whom it is addressed and may contain information that is confidential, privileged, inside information, or subject to other restrictions on use or disclosure. Any unauthorized use, dissemination or copying of this transmission or the information in it is prohibited and may be unlawful. If you have received this transmission in error, please notify the sender immediately by return e-mail, and permanently delete or destroy this e-mail, any attachments, and all copies (digital or paper). Unless expressly stated in this e-mail, nothing in this message should be construed as a digital or electronic signature.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
&lt;/pre&gt;</description>
    <dc:creator>Sergey Cherepanov</dc:creator>
    <dc:date>2012-05-23T17:49:42</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11553">
    <title>Re: Current state of the art with inotify-likefunctionality?</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11553</link>
    <description>&lt;pre&gt;
Some more comment:

I've done something similar like this (file system that accesses its own
mountpoint) for self-testing purposes (but I eventually gave up on it
and just used separate processes). You will need to be extra careful
about locking, especially *outside* of your code. Almost no library ever
assumes that even a simple opendir() call may end up in the same process
again, which can result in very tricky deadlocks if the library does not
release its locks for every system call that accesses the mountpoint.

Another thing to consider is permission checking. Your file system may
be serving directories for which it (or rather, the UID the fs is
running under) has no write rights. For these directories, normal
attempts to create files should fail, but "unmasking" requests should of
course work. This means that you need to implement your own access()
method (which you may have done already), but you also need to
distinguish between ordinary and unmasking requests, e.g. by checking
the PID of the requesting process.



Best,

   -Nikolaus

&lt;/pre&gt;</description>
    <dc:creator>Nikolaus Rath</dc:creator>
    <dc:date>2012-05-23T18:42:46</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11552">
    <title>Re: Current state of the art with inotify-likefunctionality?</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11552</link>
    <description>&lt;pre&gt;
Yeah, I guess that's true, huh.

Okay, thanks everyone.

-JT

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
&lt;/pre&gt;</description>
    <dc:creator>JT Olds</dc:creator>
    <dc:date>2012-05-23T17:28:43</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11551">
    <title>Re: Current state of the art with inotify-likefunctionality?</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11551</link>
    <description>&lt;pre&gt;
To me this sounds like the best you can possibly do in this situation,
(and I'm not sure why an additional overlay file system would be useful
in either case).

What race conditions are you worried about?

If a local client accesses a file that has been created remotely before
you have unmasked it, the situation is not different from the client
accessing it before the remote change has made it through the network.


Best,

   -Nikolaus

&lt;/pre&gt;</description>
    <dc:creator>Nikolaus Rath</dc:creator>
    <dc:date>2012-05-23T15:06:53</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11550">
    <title>【help】 Why the result shown by 'ls' after fuse mount is '?' coming with such error 'Input/output error'?!</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11550</link>
    <description>&lt;pre&gt;Hi everyone:
    I  download the example of 'helloword' in fuse.sourceforge.net and then
compile correctly,  the version of fuse on my machine is
[fuse-devel-2.7.4-8.el5]  and os-kernel 2.6.18.8;
but the running info is as follows:


[malei&amp;lt; at &amp;gt;xentest ::Wed May 23::~/test-fuse]$ mkdir mnt2
[malei&amp;lt; at &amp;gt;xentest ::Wed May 23::~/test-fuse]$ ls
hello  #hello.c#  hello.c  mnt  mnt2
[malei&amp;lt; at &amp;gt;xentest ::Wed May 23::~/test-fuse]$ ls -l
total 24
-rwxrwxr-x 1 malei malei 10445 May 23 18:36 hello
-rw-rw-r-- 1 malei malei  3572 May 23 18:33 #hello.c#
-rw-rw-r-- 1 malei malei  3466 May 23 18:34 hello.c
?--------- ? ?     ?         ?            ? mnt
drwxrwxr-x 2 malei malei  4096 May 23 18:43 mnt2
[malei&amp;lt; at &amp;gt;xentest ::Wed May 23::~/test-fuse]$ ./hello ./mnt2
[malei&amp;lt; at &amp;gt;xentest ::Wed May 23::~/test-fuse]$ ls -l
total 20
-rwxrwxr-x 1 malei malei 10445 May 23 18:36 hello
-rw-rw-r-- 1 malei malei  3572 May 23 18:33 #hello.c#
-rw-rw-r-- 1 malei malei  3466 May 23 18:34 hello.c
?--------- ? ?     ?         ?            ? mnt
?--------- ? ?     ?         ?            ? mnt2
[malei&amp;lt; at &amp;gt;xentest ::Wed May 23::~/test-fuse]$ ls ./mnt2
ls: ./mnt2: Input/output error
[malei&amp;lt; at &amp;gt;xentest ::Wed May 23::~/test-fuse]$ rpm -qa | grep fuse
fuse-libs-2.7.4-8.el5
fuse-libs-2.7.4-8.el5
fuse-devel-2.7.4-8.el5
fuse-2.7.4-8.el5
fuse-devel-2.7.4-8.el5
[malei&amp;lt; at &amp;gt;xentest ::Wed May 23::~/test-fuse]$ ls ./mnt2
ls: ./mnt2: Input/output error
[malei&amp;lt; at &amp;gt;xentest ::Wed May 23::~/test-fuse]$ uname -r
2.6.18.8-xen
[malei&amp;lt; at &amp;gt;xentest ::Wed May 23::~/test-fuse]$


    Looking forward to your reply and thanks in advance!
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
&lt;/pre&gt;</description>
    <dc:creator>马磊</dc:creator>
    <dc:date>2012-05-23T11:03:02</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11549">
    <title>setattr error</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11549</link>
    <description>&lt;pre&gt;Hello.

I have tried this.
http://code.google.com/p/python-llfuse/source/browse/contrib/example.py?name=

src/handlers.pxi:

cdef void fuse_setattr (fuse_req_t req, fuse_ino_t ino, c_stat *stat,
                        int to_set, fuse_file_info *fi) with gil:
...
attr = EntryAttributes()
...
ret = fuse_reply_attr(req, &amp;amp;stat_n, timeout)



C++. My code:

void
fsSetattr(fuse_req_t req, fuse_ino_t ino, struct stat *attr, int to_set,
    struct fuse_file_info *fi)
{
  mapAbfNodes::iterator node_iter = nodes.find(ino);

  if (node_iter != nodes.end())
    {
      abfNode&amp;amp; node = nodes[ino];

      if (to_set &amp;amp; FUSE_SET_ATTR_ATIME)
        {
          node.atime = attr-&amp;gt;st_atim;
        }

      if (to_set &amp;amp; FUSE_SET_ATTR_MTIME)
        {
          node.mtime = attr-&amp;gt;st_mtim;
        }

      if (to_set &amp;amp; (FUSE_SET_ATTR_ATIME_NOW | FUSE_SET_ATTR_MTIME_NOW))
        {
          // get time now

          timespec ntime;

          clock_gettime(CLOCK_REALTIME, &amp;amp;ntime);

          if (to_set &amp;amp; FUSE_SET_ATTR_ATIME_NOW)
            {
              attr-&amp;gt;st_atim = ntime;

              node.atime = ntime;
            }

          if (to_set &amp;amp; FUSE_SET_ATTR_MTIME_NOW)
            {
              attr-&amp;gt;st_mtim = ntime;

              node.mtime = ntime;
            }
        }

      res = fuse_reply_attr(req, attr, ATTR_TIMEOUT);
    }
  else
    {
      fuse_reply_err(req, ENOENT);
    }
...

FUSE_SET_ATTR_ATIME_NOW, FUSE_SET_ATTR_MTIME_NOW - Is it correct?

$ python example.py fs
$ touch fs/1
$

It works.

$ ./abfFS fs -f -s -c ../abffs.cfg
$ touch fs/1
touch: closing `fs/1': Input/output error
$ ls -l fs
total 1
-rw-r--r-- 1 root root    0 мая   23 10:09 1
$

Log:

fsCreate
fsSetattr
fsRelease

Why I get this error? I have checked coreutils. It returns EIO.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
fuse-devel mailing list
fuse-devel&amp;lt; at &amp;gt;lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fuse-devel
&lt;/pre&gt;</description>
    <dc:creator>Андрей Гаврилин</dc:creator>
    <dc:date>2012-05-23T06:13:14</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11548">
    <title>Re: Current state of the art with inotify-likefunctionality?</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11548</link>
    <description>&lt;pre&gt;2012/5/23 JT Olds &amp;lt;jtolds-aCMSg5yP+xoAvxtiuMwx3w&amp;lt; at &amp;gt;public.gmane.org&amp;gt;:

Yes, for me the overlay fs is a good and intuitive just approach.


No, notifyfs offers a new method, which I've described earlier:
messages via a socket.


The process with the fuse extensions? Do you mean the FUSE fs you're
writing, the fuse client?

What you describe works, but a way the server notifies the FUSE client
is required. And also since the server does not know about where the
watches are set, it has to monitor the whole "subvolume" (thus every
file and subdirectory) it exports to clients.

This whole thing would be much easier when in userspace processes can
read where ((i)notify) watches are set, and if it's on the mounted
FUSE filesystem, a  process like notifyfs or something simular can
take the right action, like forwarding the watch to the filesystem or
contacting the remote server, like you described. It's then possible
to use a local posix call, which triggers inotify.

I've tried a patch on the linux-fs maillist, which sends a message to
userspace everytime a inotify watch is set (and removed) via netlink,
but it was rejected.

Stef

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
&lt;/pre&gt;</description>
    <dc:creator>Stef Bon</dc:creator>
    <dc:date>2012-05-23T05:33:26</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11547">
    <title>Re: Current state of the art with inotify-likefunctionality?</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11547</link>
    <description>&lt;pre&gt;
whoops, I mean "keep the file hidden from the local file system"

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
&lt;/pre&gt;</description>
    <dc:creator>JT Olds</dc:creator>
    <dc:date>2012-05-23T03:10:49</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11546">
    <title>Re: Current state of the art with inotify-likefunctionality?</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11546</link>
    <description>&lt;pre&gt;Hi Stef,

Thanks for the reply! An overlay FS is an interesting approach - sort
of a separation of concerns. Good idea!

It's not completely clear to me from your email, or from the
documentation on your website, if it's possible for your overlay FS to
notify existing clients not connected through your socket-based
notification protocol. Is that possible? or must clients connect to
your notification socket?

Unfortunately my use case is constrained in that I cannot modify, but
would like to support, existing filesystem clients.

I had a conversation with some folks in the GTK channel about how
Gnome does file monitoring, and it sounds like the current best
practice for my use case is to do this:

1) If a local client is creating a file, proceed as usual. Its posix
call will hit the fuse layer through the kernel and the kernel will
trigger events.
2) If a remote client is creating a file, the process with the fuse
extensions will know about the created file, but instead of simply
making the file exist to future readdir and getattr calls, keep the
file hidden from the remote file system, and issue a posix call to
itself to create the file, thus unmasking the file. This causes the
kernel to know about the file's creation and trigger events.

I suppose that an overlay system could be constructed to do this
second thing, but as it is I'm already pretty worried about race
conditions with other client applications.

Stef (or anyone else), have you tried this approach? Or is there a
better way to support existing clients? Or am I an idiot and your
notifyfs supports this existing-client use case already?

-JT

On Tue, May 22, 2012 at 3:11 PM, Stef Bon &amp;lt;stefbon-Re5JQEeQqe8AvxtiuMwx3w&amp;lt; at &amp;gt;public.gmane.org&amp;gt; wrote:

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
&lt;/pre&gt;</description>
    <dc:creator>JT Olds</dc:creator>
    <dc:date>2012-05-23T03:09:05</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11545">
    <title>Re: mounting: ignore if already mounted</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11545</link>
    <description>&lt;pre&gt;Hello Nikolaus,


Yeah, seems I replied to the OP only.

What the OP wanted to do is check first whether the FS was already
mounted, and if not mount it, so that the mounting will not throw an
error.  But nothing prevents the FS from getting mounted between the
check and the actual mount by some other process.  So the idea here is
to run fusermount first, then check for success, preferably by relying
on some unique error-code of fusermount, or else by running
mountpoint.

This is similar to the advise on file/directory creation in
shell-scripts (or programs, for that matter): never check whether the
file/directory already exists, but simply create it --- and be
prepared to handle the errors that might result from the file already
being there.


Well, not _that_ particular race condition (two or more processes
trying to mount the same).  There still is the problem of someone else
having mounted the wrong FS at that particular mountpoint --- and here
/bin/mountpoint doesn't actually help, but you will have to look at
the output of /bin/mount (or /proc/mounts) directly (to see whether
the right thing got mounted :-).


Oh, but there is: mount (by default, without you telling it to behave
otherwise) will not mount something over a used mountpoint.  Which is
about as atomic as you're likely to get (there's still a race
condition if two processes try to mount the same thing, and you still
do not know which one will succeed, but at least you know that one
will succeed and one will not).

Sven
&lt;/pre&gt;</description>
    <dc:creator>Sven Utcke</dc:creator>
    <dc:date>2012-05-22T22:28:28</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11544">
    <title>Re: Current state of the art with inotify-likefunctionality?</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11544</link>
    <description>&lt;pre&gt;2012/5/22 JT Olds &amp;lt;jtolds-aCMSg5yP+xoAvxtiuMwx3w&amp;lt; at &amp;gt;public.gmane.org&amp;gt;:

Hi,

the issues you name I've found earlier.

By definition FUSE filesystems are not notified when a inotify watch is set.

That's not a FUSE thing, every fs is not aware of the watches. inotify
is entirly in VFS, the fs is a black box for inotify.

I've been working a filesystem fsevent monitor, and it's a FUSE fs
self. It's an overlay fs, which goal is to stay uptodate. Whenever it
detects there is change in the underlying fs it reads that change and
notifies the clients about it.

See:

http://code.google.com/p/notifyfs/

the things it does:
a. uses inotify on linux to monitor local changes
b. is able to forward a watch to client filesystems like FUSE and
network filesystems like cifs. This filesystem has to be connected to
notifyfs via a socket. This is difficult for network filesystems in
the kernel like cifs and nfs. I do not know how, I guess via netlink.
c. I'm experimenting with connecting notifyfs to a notfiyfs process on
another host. This works for example with a transparant filesystem
like sshfs. This is not the way I think things should work, but it's
nice to get this working

d. client apps are not connected via dbus, but via a simple socket
where events are send to the app (simular like inotify works).

e. I also want to check I get it working with fusesmb, another FUSE
fs, based on libsmbclient, but the necessary calls to handle a
SMB_CHANGE_NOTIFY call are not in the library yet.

So there is something, but still a lot of work.

Stef

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
&lt;/pre&gt;</description>
    <dc:creator>Stef Bon</dc:creator>
    <dc:date>2012-05-22T21:11:11</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11543">
    <title>Re: mounting: ignore if already mounted</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11543</link>
    <description>&lt;pre&gt;

Sven Utcke &amp;lt;sven.utcke-Mmb7MZpHnFY&amp;lt; at &amp;gt;public.gmane.org&amp;gt; writes:

I don't see another mail from you, so I'm not quite sure what race you
mean, but I believe that running fusermount first will just move the
race condition to a different spot.

I think there is no atomic "mount only if path is not yet a mountpoint"
operation in the Linux kernel, so a userspace program is fundamentally
unable to implement this functionality without race conditions. 


Best,

   -Nikolaus

&lt;/pre&gt;</description>
    <dc:creator>Nikolaus Rath</dc:creator>
    <dc:date>2012-05-22T17:55:47</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11542">
    <title>Re: mounting: ignore if already mounted</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11542</link>
    <description>&lt;pre&gt;
Ok, that's neater than my manually parsing the output of mount.  But
it still doesn't cure the race condition, so my advice stands to run
fusermount (sshfs) first, and only if that fails (and the error-code
for "there's already another FS mounted at this point" is ambiguous)
use mountpoint to find out whether anything is mounted there or not.

Sven
&lt;/pre&gt;</description>
    <dc:creator>Sven Utcke</dc:creator>
    <dc:date>2012-05-22T15:00:07</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11541">
    <title>Re: mounting: ignore if already mounted</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11541</link>
    <description>&lt;pre&gt;
Use the "mountpoint" command.


Best,

   -Nikolaus

&lt;/pre&gt;</description>
    <dc:creator>Nikolaus Rath</dc:creator>
    <dc:date>2012-05-22T13:42:04</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11540">
    <title>Re: function of Flags and Lock in read/write calls?</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11540</link>
    <description>&lt;pre&gt;

    commit f33321141b273d60cbb3a8f56a5489baad82ba5e
    Author: Miklos Szeredi &amp;lt;mszeredi-AlSwsSmVLrQ&amp;lt; at &amp;gt;public.gmane.org&amp;gt;
    Date:   Thu Oct 18 03:07:04 2007 -0700
    
        fuse: add support for mandatory locking
        
        For mandatory locking the userspace filesystem needs to know the lock
        ownership for read, write and truncate operations.
        
        This patch adds the necessary fields to the protocol.

I haven't looked into mandatory locking and don't remember why exactly
this was needed.

Thanks,
Miklos

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
&lt;/pre&gt;</description>
    <dc:creator>Miklos Szeredi</dc:creator>
    <dc:date>2012-05-22T12:57:14</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11539">
    <title>Current state of the art with inotify-likefunctionality?</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11539</link>
    <description>&lt;pre&gt;Hey gang,

I'm writing a network filesystem using fuse. Remotely, files are
getting added to the filesystem, and I would like graphical file
browsers to find out about remote changes. My fuse client definitely
knows about them, but I'm having a rough time thinking of ways to best
trigger that notification up the stack to the operating system and
various client applications. Obviously the best case scenario would be
if there was inotify/fuse integration, but as far as I can tell from
mailing list backlogs, that's not quite in yet. It appears there's
some filehandle polling now available or something?

So, my question is two-fold:

1) What is the current status for having fuse clients be able to
notify the kernel of changes to the system?

2) From a more pragmatic perspective, if fuse is unable to
as-it-stands provide the functionality I need, I would like to roll
this project out to users with existing versions of Linux. Has anyone
attacked this problem in some other way? Basically - I have Nautilus
open (or Finder on Mac OS X with Fuse4x), and a remote file/directory
changes, and I want to indicate to the user that the change happened -
so I've considered having my fuse client call out to the operating
system to touch files in itself (hacky, and doesn't trigger a creation
notification), having my fuse client call out to actually create files
in itself (hackier, and doesn't work as the file already exists, and
removing it temporarily for the create to succeed is a huge race
condition), having my client dump events into the GLib file monitor
library (only works for things using GLib), making DBus calls to tell
Nautilus to refresh (even more specific than GLib), etc, etc. Has
anyone tried tackling this problem and now has wisdom for me?

Thanks

-JT

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
&lt;/pre&gt;</description>
    <dc:creator>JT Olds</dc:creator>
    <dc:date>2012-05-22T01:12:21</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11538">
    <title>Re: readdir question about directory entries</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11538</link>
    <description>&lt;pre&gt;I have 1 more question. Let's assume that i have an create operation:

341 int proxy_create(const char *path, mode_t mode, struct fuse_file_info
*file    )
342 {
343         int l=strlen(dstdir)+strlen(path);
344         char *r,*c=(char *)malloc(l);
345         memset(c,0,strlen(c));
346         strncpy(c,dstdir,strlen(dstdir));
347         r=strncat(c,path,l-1);
348         int fh=creat(r,mode);
349         file-&amp;gt;fh=fh;
350         free(c);
351         return fh;
352 }

If my understanding is good this fails because an file handler ID for my
fuse process can't be used in other processes like touch witch invoke this
function via syscalls?

Similar open function will fail from same reason?

Greg.

2012/5/19 Grzegorz Dwornicki &amp;lt;gd1100-Re5JQEeQqe8AvxtiuMwx3w&amp;lt; at &amp;gt;public.gmane.org&amp;gt;

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
&lt;/pre&gt;</description>
    <dc:creator>Grzegorz Dwornicki</dc:creator>
    <dc:date>2012-05-21T21:45:40</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11537">
    <title>mounting: ignore if already mounted</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/11537</link>
    <description>&lt;pre&gt;This is more of a user question than a developer question, but anyway...
I wanted to create some scripts for mounting various fuse file systems I
use. (E.g., sshfs to my remote server.) I wanted each script to be able
to act in the following way:

1) if FS not mounted, mount it.
 A) if mount succeeds return success
 B) if mount fails, return failure
2) if FS already mounted, return success

The idea being: I can run the script even if I forgot I already mounted
the file system, and in such case, the script won't return a fail code.
However, I'm not sure how to distinguish in my script between situation
1B and 2, because in both cases sshfs (or whatever) returns a failure
code. So, is there a specific command/option I should use to check first
if the file system is mounted? Or some other trick?

&lt;/pre&gt;</description>
    <dc:creator>Christopher Howard</dc:creator>
    <dc:date>2012-05-21T20:21:54</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.file-systems.fuse.devel">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.file-systems.fuse.devel</link>
  </textinput>
</rdf:RDF>

