This is the mail archive of the
mailing list for the Cygwin project.
Re: Flakiness; libdups? and MS-POSIX privileges?
- From: Linda Walsh <cygwin at tlinx dot org>
- To: cygwin at cygwin dot com
- Date: Thu, 13 Mar 2008 17:16:44 -0700
- Subject: Re: Flakiness; libdups? and MS-POSIX privileges?
Dave Korn wrote:
Ah. So the error only arises when the binary is located in windows system
dir. Right alongside all those thousands of DLLs. All those DLLs which are
now all of a sudden higher up in the DLL search path than they were when the
binary was located somewhere else.
Just a WAG, but that could be significant.
Yeah. That thought occurred to me as well. However there are
no libs in the windirs of the pattern "cyg*.dll". Those _should_ be
the key libs, though let me check for any other possible dups...
/tmp> for d in /bin /windows /windows/system32;do
log="$(echo $d|sed -r 's!/(...)[^/]*!\1!g')dll.txt"
'ls' -1 "$d"/*.dll >$log
/tmp> wc -l *dll.txt
/tmp> cat *dll.txt|tee rawconcat.lst|sort|tee sorted_concat.lst|\
uniq -d >zdups.lst; wc -l *.lst|grep lst
It doesn't appear that there should be any conflicts...unless I messed
something else up...
The native API, to the very best of my knowledge, exports exactly the same
set of interfaces to every subsystem. Can you explain exactly what you're
talking about here?
(reading ahead)...so MS is back to their old *illegal* tricks?
Wasn't them using "private" or "hidden" interfaces in the OS to make
their products run better one of the reasons for the monopoly suit -- or
an unfair trade-practice type suit?
If they really only permit their version of a "POSIX" subsystem
to use certain WinNT calls, it would seem that's using their monopoly
power to exclude or degrade functionality in cygwin. IANAL (but I've
been exposed to a few and seen them on TV! :-)), but that practice would
seem to be of questionable legality.
Maybe while MS is "feeling in the mood" (forced by EU decisions) to
release specs of internals, someone (of properly, appropriate legal
'scariness') could nudge them on this if it would be useful to the cygwin?
I wonder -- haven't tested it, but wonder if their posix
implementation handles allowing the removal of open files properly.
They could "do it under the covers"...any attempt to delete an open
file or write to an open file would silently move the locked file
to some 'temporary name' and mark it "delete-on-close" -- or at
worst, add it to the "pending delete&rename registry key" to be
deleted at next boot.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html