[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.062 / U:0.676 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site