Re: [Nautilus-list] Nautilus + smbclient

On Tue, Jun 05, 2001 at 04:25:15PM -0500, Jamin Philip Gray wrote:
> >     Alex> On Tue, 5 Jun 2001, Danan Sudindranath wrote:
> >     >> 
> >     >> Why can't you just mount the smb with the smbfs kernel module and
> >     >> navigate the directory from there? That worked for me (until of
> >     >> course the smbfs module locked my kernel while transfering large
> >     >> files, does that happen to anyone else?)
> > 
> >     Alex> Of course you *can* do that. But do you want to force user to do
> >     Alex> that?  That's not very good for a graphical file-manager, is it?
> > 
> > That *is* the Unix filesystem model - a single-rooted unified filesystem.
> > When I run "make xconfig" in /usr/src/linux I typically see between five and
> > ten filesystem types to choose from.  Is Nautilus going to need
> > filesystem-specific code for all the different types of filesystems people
> > might want to browse?  What's so special about smb?
> I'm wondering the exact same thing.  Maybe I don't understand the
> issues fully, but it seems that this should be handled at the kernel
> level.  If you have a floppy or cdrom mounted or nfs shares or smb
> shares, whatever, they have mount points and you browse at that mount
> point and it all just works no matter what you are using to browse
> (command line, nautilus, a file selection dialog).  Where exactly does
> gnome-vfs fit in?  Why can't nautilus deal with floppy/cdrom drives
> and other mounted volumes in exactly the same manner?
> It seems like there is some obfuscation going on here.  It doesn't
> feel like it has to be this complicated.

1) There are some things for which there are no kernel filesystems (eg: WebDAV,
   ftp, etc)
2) There are some things you wouldn't want done in the kernel (eg: WebDAV, ftp,
3) We need to be able to mount things as a user other than root
4) There are operating systems other than Linux which use GNOME (eg: Solaris,
   *BSD, etc) so kernel modules are not really generally useful for GNOME.
5) There are extended semantics and functionality we can provide that the
   standard kernel/POSIX APIs don't provide (eg: metadata, notification, copy
   and move abstraction, etc).


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]