Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <418796A4.30302@x-ray.at>
Date: Tue, 02 Nov 2004 15:16:04 +0100
From: Reini Urban <rurban AT x-ray DOT at>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.7.3) Gecko/20040910
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: getmntent extended
References: <41850016 DOT 90204 AT x-ray DOT at> <Pine DOT GSO DOT 4 DOT 61 DOT 0411011159390 DOT 13237 AT slinky DOT cs DOT nyu DOT edu>
In-Reply-To: <Pine.GSO.4.61.0411011159390.13237@slinky.cs.nyu.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes

Igor Pechtchanski schrieb:
> On Sun, 31 Oct 2004, Reini Urban wrote:
>>Is it possible to let getmntent() i.e. fillout_mntent()
>>return something more appropriate?
>>or would this break existing apps?
>>
>>getmntent() currently returns either "system" or "user" (user or system
>>mounts), which are kinda strange fstype names.
>>
>>I expected them to return something like "msdos", "pc", "fat", "vfat" or
>>"ntfs". Those are currently supported by current findutils on mounted dos
>>drives in unix systems.
>>Maybe also an indiciator for subst'ed drives: "subst" and remote shares, but
>>this has no equivalent at unix.
>>
>>Apps using this are to my knowledge only
>>df -t <type>, and find -fstype <type>
>>I could change that in coreutils and findutils, as findutils also adds some
>>logic for certain esoteric platforms, but I thought asking for it upstream
>>costs nothing.
>>[snip]
> 
> 
> Yes, it's possible: <http://cygwin.com/ml/cygwin/2002-09/msg01035.html>.
> But, <http://cygwin.com/acronyms/#SHTDI>...

Ok, we agreed now that it's a good thing.
Have you already started?

http://cygwin.com/ml/cygwin/2002-09/msg01044.html
 >"If people agree it's a good idea, I'll start on the implementation.
 >	Igor"

Idea:
use mnt->mnt_type from GetVolumeInformation().lpFileSystemNameBuffer
move user/system from mnt->mnt_type to mnt->mnt_opts
add more mnt->mnt_opts
fix all the places like m->issys
add extended output (all opts) to cygcheck.cc, as in mount

If we agree mnt->mnt_opts will have then the following optional 
comma-seperated strings: (current state)
   system/user, textmode/binmode, cygexec/exec/noexec,
   managed, noumount

other useful options to consider, gathered by GetVolumeInformation():
   compressed, case-preservant, case-sensitive, encrypted, read-only

other useful options to consider, gathered by GetDriveType():
   no-root-dir, emovable, remote, cdrom, ramdisk

additional checks to be done for SUBST:
   subst

we should leave out default options, and only store them if they are 
non-default, ok?
so we should assume no-case-preservant on FAT and case-preservant on 
NTFS. no-case-sensitive on all windows drive types.
maybe sooner or later someone will come up with mounting external drive 
types (iso9660, ext2fs) also. (Daemon-Tools, e2fsimage, ...)

BTW: The research at the mail above forgot about getmntent() and 
fillout_mntent() in path.cc. fillout_mntent() is the main worker.

If not I'll start also, 'cause I want that feature in coreutils and 
findutils.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/