getmntent extended

[Reini Urban]

Igor Pechtchanski schrieb:
> On Tue, 2 Nov 2004, Reini Urban wrote:
>>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"
> 
> 
> No, I haven't started, unfortunately.  Feel free to take over.

I'll start and post a patch to be considered.

>>Idea:
>>use mnt->mnt_type from GetVolumeInformation().lpFileSystemNameBuffer

probably converted to lowercase for consistency with unix. right?

>>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
> 
> It might be better to make those flags instead...

flags?

struct mntent
{
   char *mnt_fsname;
   char *mnt_dir;
   char *mnt_type;
   char *mnt_opts;
   int mnt_freq;
   int mnt_passno;
};

this is all we have. all the "flags" are carried in mnt_opts.
and then picked up by apps like df or find.
there's no union or enum of flags in struct mntent which would enable a 
fast logior check. only comma seperated options.
struct vmount with flags (remote et al) is only on AIX.

coreutils/lib/mountlist.c has plenty of options to interpret struct 
mntent. cygwin currently uses MOUNTED_GETMNTENT1
config.h:
/* Define if there is a function named getmntent for reading the list of
    mounted filesystems, and that function takes a single argument.
   (4.3BSD, SunOS, HP-UX, Dynix, Irix) */
#define MOUNTED_GETMNTENT1

>>other useful options to consider, gathered by GetVolumeInformation():
>>  compressed, case-preservant, case-sensitive, encrypted, read-only
> 
> Again, flags.
> 
> 
>>other useful options to consider, gathered by GetDriveType():
>>  no-root-dir, emovable, remote, cdrom, ramdisk
> 
> This should be fstype.
> 
> 
>>additional checks to be done for SUBST:
>>  subst
> 
> So is this.
> 
> IIRC, what started this was a problem with 'find -xdev' which used a
> (wrong) heuristic for determining remote drives (colon in the path) that
> worked in reverse on Cygwin.  Is 'find' still part of findutils, or has it
> moved to coreutils?  

no, unfortunately find is still in findutils, at 4.1.20 which I use 
currently, and a new 4.2.0 on the horizon.
find has also xargs, updatedb and locate.

I originally just wanted updatedb to add a --list <MANIFEST> option for 
faster setup/postinstall updatedb. currently it takes about 2min.
Similar to makewhatis updates, which is even slower.

> In any case, does the new version still have this bug?  

find has still a lot of bugs, but there are a lot of patches at the 
savannah site, which i'm trying out. some fixes and some new features.

haven't checked find -xdev brokenness yet. good to know about ":"
should I upload my findutils-4.1.20 package to my private site?
or wait until I have a working fstype and xdev patch?

> If so, it should be fixed to use the fstype field of the mntent...

currently it uses only the mnt->mnt_type field.

> Or is there a local/remote flag?

there's still no local/remote flag to my knowledge.
coreutils df --local would be good to support. another TBD entry.

df currently uses these macros:
/* A file system is `remote' if its Fs_name contains a `:'
    or if (it is of type smbfs and its Fs_name starts with `//').  */
# define ME_REMOTE(Fs_name, Fs_type)	\
     (strchr ((Fs_name), ':') != 0	\
      || ((Fs_name)[0] == '/'		\
	 && (Fs_name)[1] == '/'		\
	 && STREQ (Fs_type, "smbfs")))

# define ME_DUMMY(Fs_name, Fs_type) \
     (!strcmp (Fs_type, "autofs") \
      /* for Irix 6.5 */ \
      || !strcmp (Fs_type, "ignore"))

Note: ME_DUMMY is wrong. either add our "unknown" here or fix 
cygwin1.dll to use the Irix "ignore" instead of our "unknown". But this 
looks awful. Better fix this macro here for CYGWIN.
/cygdrive e.g. will return "unknown"
cgf?

>>we should leave out default options, and only store them if they are
>>non-default, ok?
> 
> I don't see why, frankly.  If you use the flags approach, just make the
> default values be 0's... :-D
> 
> 
>>so we should assume no-case-preservant on FAT and case-preservant on NTFS.
>>no-case-sensitive on all windows drive types.
> 
> I'd add a bit of logic for NTFS to set the case-preservant flag.  The
> case-sensitive vs. case-insensitive is reasonably meaningless on Cygwin,
> since it's controlled by the "check_case" option in $CYGWIN (which
> hopefully will not be removed anytime soon [@Corinna])...

case_global is only app specific. (every app can use their own CYGWIN env)
case-sensitive and managed are drive/mount specific. it's good to have a 
seperation here.
since case_global is only app specific we cannot assume defaults for 
mnt_opts, which are global.
we can only assume defaults for specific fstypes.

>>maybe sooner or later someone will come up with mounting external drive
>>types (iso9660, ext2fs) also. (Daemon-Tools, e2fsimage, ...)
> 
> It's already possible, using non-Cygwin tools, but that doesn't mean
> people won't do this.  Other possible useful types to distinguish are
> Unix->Samba drives and Clearcase drives...

For "SUNWNFS" there's already some special logic. what fstype string 
returns Clearcase?
Samba uses "smbfs" and is already correctly detected as remote.

There's also some unneeded logic, which checks all fstypes at runtime
path.cc fs_info::update(), which can simply be converted to use struct 
mntent entries, which are calculated only once.
the question is if the binary checks at runtime are faster then the 
string checks once. need to time this.

-- 
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/