extracting shares from mtab

[Robert Lunnon]

Mon, 10 Dec 2001 00:06, you wrote:
> Message: 6
> Date: Sat, 08 Dec 2001 18:38:57 -0500
> From: Gavriel State 
> Organization: TransGaming Technologies Inc.
> To: Alexandre Julliard 
> CC: Dan Kegel , Eric Pouech ,
>         [e-mail], [e-mail]
> Subject: Re: UNC patch & parsing fstab/mtab
>
> Alexandre Julliard wrote:
> > Dan Kegel  writes:
> >  
> >  > Just how terrible is parsing /etc/mtab?  It doesn't look like
> >  > much code.  I'd be happy to provide a nice OO wrapper object
> >  > for it if that would make you happier.  It would then no
> >  > longer be an ugly hack.  Would that satisfy you?  Or are
> >  > you fundamentally opposed to it for some other reason than
> >  > code clarity?
> >  
> >  Code clarity is one thing (it should be probably using getmntent and
> >  friends), performance is another (parsing /etc/mtab on each CreateFile
> >  is *not* a good idea), but mainly I'm opposed to the concept of
> >  configuring everything by hand except magically getting smb shares
> >  through /etc/mtab, when they may not at all reflect what you want the
> >  Windows application to see. It doesn't fit in the current
> >  configuration philosophy. Now of course the config philosophy can be
> >  changed, but it must remain coherent.
>
> I don't doubt that we don't want to be parsing /etc/mtab on each
> CreateFile, but I will put in a word for some modifications to the
> configuration philosophy when it comes to drive letters.
>
> One of the problems we've come across recently is this: for games that
> use copy protection, we need to have direct access to the device that
> a CD-ROM drive uses.  For the moment, this relys on the user to manually
> configure their drive letters.  From what we've seen, doing so is
> beyond the ken of many of our users.
>
> As such, we've put together a scheme for parsing /etc/fstab on startup
> (not mtab: the drive may not be mounted), and automatically adding
> drive letters for each iso9660 filesystem listed.  The patch (to the
> WineX tree) is here:
>
> http://www.geocrawler.com/archives/3/9376/2001/11/0/7204310/
>
> We're happy to contribute this in our next outward merge if people
> think it's useful.
>
> -Gav

Oh no not again

Except for us poor people that dont use linux !

On Solaris fstab is vfstab, and mtab is mnttab, parsing these files is no 
good unless it is done in some portable way. (Not that smbfs even works on 
Solaris)  I would think that persistent share selection should be saved in 
the registry and accessed through smbclient rather than smbfs, then smb 
shares would work for all OSs supporting Samba, not just those supporting 
smbfs.

IMHO There are already too many linux centrix assumptions in wine, please, 
lets not add any more .

Bob

[Chris Green]

--snip--
> On Solaris fstab is vfstab, and mtab is mnttab, parsing these files is no
> good unless it is done in some portable way. (Not that smbfs even works on
> Solaris)  I would think that persistent share selection should be saved in
> the registry and accessed through smbclient rather than smbfs, then smb
> shares would work for all OSs supporting Samba, not just those supporting
> smbfs.
>
> IMHO There are already too many linux centrix assumptions in wine, please,
> lets not add any more .

Perhaps the note below (from the linux man page for getmntent(3)) might be 
relevant or useful to someone who wants to implement such a thing in a 
portable way?

"SysV  also  has a getmntent() function but the calling sequence differs, and 
the returned structure is different. Under SysV /etc/mnttab is used.  BSD 4.4 
and  Digital  Unix  have  a  routine getmntinfo(), a wrapper around the 
system call getfsstat()."

regards
Chris

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

[Dan Kegel]

Chris Green wrote:
> > IMHO There are already too many linux centrix assumptions in wine, please,
> > lets not add any more .
>
> Perhaps the note below (from the linux man page for getmntent(3)) might be
> relevant or useful to someone who wants to implement such a thing in a
> portable way?
>
> "SysV  also  has a getmntent() function but the calling sequence differs, and
> the returned structure is different. Under SysV /etc/mnttab is used.  BSD 4.4
> and  Digital  Unix  have  a  routine getmntinfo(), a wrapper around the
> system call getfsstat()."

Agreed, if wine were to want to enumerate mounted volumes,
it should do it carefully with a wrapper function
to avoid portability problems.

Amazing that SUS doesn't provide a portable way to do this.
- Dan