This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: getmntent extended
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/