This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Deprecating ntea


Igor Peshansky wrote:
On Tue, 27 Feb 2007, Corinna Vinschen wrote:

As the subject says, I'm all for deprecating the ntea setting.

The reason is that it's just an ugly fake.  It's not at all necessary
and I even consider it as dangerous, because it pretends a security
(permission bits) which doesn't exist.

Does anybody have a good argument to keep this cruft against all reason?

The ntea permission bit support isn't there to fool (most) users, it's there to fool (arguably broken) applications that assume they are on a secure system and check the permissions. IIRC, Linux does not support permission setting on FAT filesystems, so no sensitive data can reside on them. The answer for Unix is WDDTT. The answer for Windows is more complex, as many people may not have a choice. That's where ntea comes in.

I'm not arguing for keeping ntea, but I am arguing for having *some*
mechanism to help users run Unix applications on filesystems without
security support (how many people still use rsh?).  As I see it, ntea as
it stands now is broken anyway (it doesn't work on FAT32).  However, does
it really slow down the common path (i.e., NTFS)?  If all ntea support
kicks in after the FS is determined to be FAT, then it may be more a
matter of refactoring the code to make it simpler, rather than
performance.  However, simpler code is good, so that in itself may be a
good reason to remove ntea.

Right now Cygwin doesn't have a concept of "filesystem drivers" (well,
there's the fhandler* interface, but it doesn't discriminate between NTFS,
FAT, FAT32, SAMBA, etc).  One idea may be to allow pluggable drivers for
various filesystems (with a default fallback for unrecognized ones), and
move all the ntea code into the FAT "driver".  Then people who are
interested in running on FAT can provide patches to support ntea if they
so choose (perhaps even outside of the main "cygwin" package, as a
separate auto-loaded DLL).  Yes, I know, SHTDI.

In short, if the main list does not complain loudly, ntea is a goner.  But
if they do, perhaps soliciting help in getting the above refactoring done
is the way to go.
	Igor


There are definitely better ways for ntea to be managed in the code if it's
going to be kept.  I would agree that if we're going to keep it, we should
be thinking about some kind of restructuring like this if for no other
reason than there will come a day where it is of absolutely no value.  So it
would make removing it simpler. ;-)

I'm wondering if there's really allot of call for it though.  Either
everybody that needs it has somehow miraculously found it (through the
FAQ or docs) or nobody is using it.  The former possibility assumes people
read the docs, which definitely doesn't fit the majority profile.  The
latter implies ntea isn't needed.

I can't imagine that there are many NT4 or better machines out there that
rely on FAT (not FAT32) solely.  The last W2K machine I bought 6+ years
ago offered the option to come preinstalled as FAT but was actually FAT32.
I don't know of anyone pre-installing XP on a machine who is offering FAT.
In my opinion, people using FAT on any sizable (i.e. usable) partition with
at least W2K or XP are actually using FAT32.  Unless there's some trick out
there to enable support for ntea on FAT32, I think it's fair to say that
ntea has already been killed by MS.

To me it seems ntea has enough limited applications that it is effectively
unusable.  But I agree with Chris that this needs to be announced on the
main list before killing it off for 1.7.

--
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
216 Dalton Rd.                          (508) 893-9889 - FAX
Holliston, MA 01746


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]