[lkml]   [2005]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: FUSE merging?
    > 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 may confuse the user. It may even confuse the kernel for
    sticky directories(*). But basically it just works, and is very

    > Not really a criticism, just curious. This doesn't so much relate
    > to FUSE, but I've been wrestling with what to do about this chunk of
    > (mapping) code -- it seems like it might be a good idea to have some
    > common code shared amongst the networked file systems to handle this
    > sort of thing. The NFS idmapd service seems overcomplicated, but
    > something like that in the common code could provide the same level
    > of service. What do folks think? Should someone (me?) take a whack
    > at a common id mapping service for the kernel (or just extract
    > idmapd from NFS) -- or is this something better implemented
    > filesystem-to-filesystem?

    If more than one filesystem would use it, it would make sense to
    abstract it out. FUSE doesn't need it since it can happily do the
    mapping in userspace.


    (*) I think the correct behavior would be if checking sticky
    permissions could also be delegated to the filesystem, like checking
    normal permissions can be.
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-09-03 16:23    [W:0.050 / U:45.580 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site