Domain user cannot login to remote PC
Hello gurus,
In order to access a remote PC, I updated /etc/group and
/etc/passwd on the remote PC.
/etc/group contains:
SYSTEM:S-1-5-18:18:
None:S-1-5-21-1681026574-976757939-617630493-513:513:
Administrators:S-1-5-32-544:544:
Backup Operators:S-1-5-32-551:551:
Guests:S-1-5-32-546:546:
Power Users:S-1-5-32-547:547:
Replicator:S-1-5-32-552:552:
Users:S-1-5-32-545:545:
Domain Users:S-1-5-21-220523388-688789844-725345543-513:10513:
/etc/passwd contains:
SYSTEM:*:18:544:,S-1-5-18::
Administrators:*:544:544:,S-1-5-32-544::
Admin:*:501:513:U-RRBACK\Admin,S-1-5-21-1681026574-976757939-617630493-501:/home/Admin:/bin/bash
isoft:*:1007:513:RR
isoft,U-RRBACK\isoft,S-1-5-21-1681026574-976757939-617630493-1007:/home/isoft:/bin/bash
IUSR_RRBACK:*:1000:513:Internet Guest
Account,U-RRBACK\IUSR_RRBACK,S-1-5-21-1681026574-976757939-617630493-1000:/home/IUSR_RRBACK:/bin/bash
sshd:*:1008:513:sshd
privsep,U-RRBACK\sshd,S-1-5-21-1681026574-976757939-617630493-1008:/var/empty:/bin/bash
TsInternetUser:*:1001:513:TsInternetUser,U-RRBACK\TsInternetUser,S-1-5-21-1681026574-976757939-617630493-1001:/home/TsInternetUser:/bin/bash
magr40:*:12085:10513:magr40,U-TCAD\magr40,S-1-5-21-220523388-688789844-725345543-102085:/home/magr40:/bin/bash
When I connect from the local PC, it fails on magr40's password:
[magr40@gj2qf0j]~:{33}:$ ssh magr40@rrback
Could not create directory 'home/magr40/.ssh'.
The authenticity of host 'rrback (1.2.3.4)' can't be established.
RSA key fingerprint is ab:...:8d.
Are you sure you want to continue connecting (yes/no)? yes
Failed to add the host to the list of known hosts
(home/magr40/.ssh/known_hosts).
magr40@rrback's password:
Permission denied, please try again.
I have created /home/magr40 and /home/magr40/.ssh, and the
problem still persists.
Should I have created these files on the remote PC manually ?
What am I supposed to do to allow magr40 access the remote PC ?
Any hints will be greatly appreciated.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
emacs and mice, that is linux curses control of ssh and rxvt terminal
I have a slow connection to a remote machine. I can use X to connect to it, but I would prefer to: rxvt ssh to the machine emacs -nw And this works pretty well. But there is no mouse control. (If it matters, on the linux target, I am running the gpm service.) Is it possible to get a working mouse in a terminal emacs window? I would like to cut and paste, but actually more important for my fingers for some reason, is the ability to drag the emacs window borders to shrink and enlarge one emacs window relative to another (as in shrink-window-horizontally). Is this possible? What does it take on the Linux side? What does it take on the Cygwin side? (And I did try google, the faq, and a search of the mailing list archives.) Thanks for your time, Jerry Asher -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: rxvt, once again...
On Sat, 28 Dec 2002 19:19:09 -0800, Shankar Unni <[EMAIL PROTECTED]> wrote: > > In Win98 and Me, you cannot drag and expand the window, or set a buffer > size larger than the window size. Period. Don't know if they have > deliberately crippled XP Home to match Me (I don't have XP Home to check..) The XP home `cmd' is not crippled (it can be resized horizontally and vertically and have buffer larger than the screen). Ehud. -- Ehud Karni Tel: +972-3-7966-561 /"\ Mivtach - Simon Fax: +972-3-7966-667 \ / ASCII Ribbon Campaign Insurance agencies (USA) voice mail and X Against HTML Mail http://www.mvs.co.il FAX: 1-815-5509341 / \ mailto:[EMAIL PROTECTED] Better Safe Than Sorry -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Small wingdi.h bug
The following prototype in wingdi.h should not have the CONST qualifier for COLORREF. Perhaps it was mis-copied from the wglSet... function? WINGDIAPI int WINAPI wglGetLayerPaletteEntries(HDC, int, int, int, CONST COLORREF *) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Hard links broken?
Nicolas,
You've got something else going on. I, too, am running Cygwin 1.3.17
('cause of my other problems with 1.3.18) and hard links work fine for me.
I assume you are using an NTFS file system, right? FAT file systems don't
support hard links.
I have noticed that Cygwin's link code falls back to copying for more
reasons than just lack of support for hard links in the underlying file
system. If I knew more about what variety of failures in attempting to
create a hard link will cause Cygwin to fall back to copying the file, I'd
tell you, but I just remember seeing other things do it.
What are the ownership and permissions of the directory in which the files
involved reside? How do they relate to the user (id) making the attempt?
Randall Schulz
P.S. Nicolas, please subscribe to the list, at least for as long it takes
to get this issue resolved.
At 20:29 2002-12-27, Nicolas Williams wrote:
So, I upgraded to Cygwin 1.3.17-1 this weekend and mutt started behaving
oddly (I upgraded mutt as well). My laptop runs Windows XP (SP1).
The behaviour is this: it fails to lock the mail spools and thinks some
other process has the spools locked and prompts me as to whether to
remove the lock files after timing out.
Besides being very obnoxious this behaviour is very obnoxious.
So I straced mutt and the problem appears to be that the call to link()
a file to the lock file name fails, but it does actually copy the file.
So, I did this:
% touch foobar
% ln foobar foobar.lock
% ls -li foobar foobar.lock
3893364076 -rw-r--r--1 myuser None0 Dec 27 22:09 foobar
3895124156 -rw-r--r--1 myuser None0 Dec 27 22:09 foobar.lock
%
So hard links don't work now.
Here's a snippet from the strace output:
(first the spoolfile.. is created)
..
118 2609558 [main] mutt 4024 normalize_posix_path: src myuser.lock
111 2609669 [main] mutt 4024 cwdstuff::get: (/var/spool/mail) =
cwdstuff::get (0x22DB38, 260, 1, 0
), errno 2
500 2610169 [main] mutt 4024 symlink_info::check: not a symlink
77 2610246 [main] mutt 4024 symlink_info::check: 0 = symlink.check
(C:\cygwin\var\spool\mail\myuser
.lock, 0x22D7F8) (0xA)
115 2610361 [main] mutt 4024 link: file
'C:\cygwin\var\spool\mail\myuser.lock' exists?
63 2610424 [main] mutt 4024 link: -1 = link (myuser.MYUSER.4024,
myuser.lock)
..
But, before mutt gets to this point the lock file (myuser.lock) does not
exist, and yet it exists from that point forward.
Should I install and earlier Cygwin release? How should I do that?
Thanks,
Nico
PS: I'm not on the list.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
tar wildcard problem
I got some problem using tar. * wildcard in -T doesn't work. If I include *.txt in the file list I got tar: *.txt: Cannot stat: No such file or directory However using *.txt in command line do work. Putting exact file name or directory in the file list also works. * wildcard in -X file doesn't work. However, if I use it in --exclude it does work. Putting exact file name doesn't work either. So -X does nothing for me. The version information is tar (GNU tar) 1.13.25 Copyright (C) 2001 Free Software Foundation, Inc. This program comes with NO WARRANTY, to the extent permitted by law. You may redistribute it under the terms of the GNU General Public License; see the file named COPYING for details. Written by John Gilmore and Jay Fenlason. Hope you can give me some suggestion. Thank you, Wai yip Tung -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Cannot use zlib with Mingw
I was trying to compile a program which uses zlib with Mingw (i.e. with
the flag -mno-cygwin) but the compilation failed because zlib.h could not
be found. No problems with standard Cygwin compilation.
Probably, if -mno-cygwin is used, only the directory /usr/include/mingw
is searched, /usr/include is not. Well, the flag -I/usr/include could be
added, but I am afraid some header files could conflict.
To reproduce the problem: type this simple file
#include
int main(){
return 0;
}
and compile it with
gcc -c -mno-cygwin .c
The error is "zlib.h: No such file or directory". No problems at all if
gcc -c .c
is launched)
Is there a way to get round this problem?
__
Tiscali ADSL: abbonati entro il 31 gennaio.
Non paghi l'attivazione.
Non paghi il primo mese.
http://www.tiscali.it/adsl
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re:Strange behaviour of gcc
From: Randall R Schulz To: cygwin at cygwin dot com Date: Tue, 24 Dec 2002 08:16:59 -0800 Subject: Re:Strange behaviour of gcc References: <[EMAIL PROTECTED]> >Stack space is usually far more limited than heap >space, which I assume is what motivates this behavior >in the code generator. The programming language's >semantics are maintained. What I would like to do is to build a DLL which does not link to the C runtime library (and therefore it does not have access to _alloca or other CRT functions). The executable dynamically loads the DLL with dlopen() and the DLL calls some callback functions provided by the executable. The DLL's size is about 20KB if it links to CRT, 8KB if it does not. The main motivation is to have a small file. So, is there a gcc option which allows not to call _alloca (even if the performance is sub-optimal)? Regards Fabrizio __ Tiscali ADSL: abbonati entro il 31 gennaio. Non paghi l'attivazione. Non paghi il primo mese. http://www.tiscali.it/adsl -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Strange behaviour of gcc
>-- Messaggio Originale -- >From: "Max Bowsher" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]>, > <[EMAIL PROTECTED]> >Subject: Re: Strange behaviour of gcc >Date: Mon, 23 Dec 2002 23:25:00 - > > >[EMAIL PROTECTED] wrote: >> Can somebody explain why gcc (version 3.2 20020927) on Cygwin does >> this? > >Yes. Gcc's optimizer chose to make a large amount of local variable >allocation into an alloca call. > >Does it matter? For what I'm trying to do, it does. I would like to build a DLL which is not linked to the C runtime library in order to have a smaller file (a trick copied from Winamp plug-ins), and I don't mind about sub-optimal performance. The executable dlopen()s the DLL and provides some callbacks to it. If the DLL is linked to CRT, it is 20KB long. If it is not, it is 8KB long (but obviously it does not have alloca available). Is there a gcc option to build code without the call to alloca? __ Tiscali ADSL: abbonati entro il 31 gennaio. Non paghi l'attivazione. Non paghi il primo mese. http://www.tiscali.it/adsl -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re:Strange behaviour of gcc
> > GCC's __builtin_alloca uses a helper function called _alloca to check the > stack > whenever allocating more that 4000 bytes in one go. > > Danny To disable stack probing, add this switch -mno-stack-arg-probe. Danny http://movies.yahoo.com.au - Yahoo! Movies - What's on at your local cinema? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: emacs and mice, that is linux curses control of ssh and rxvtterminal
/ Jerry Asher <[EMAIL PROTECTED]> wrote: | I have a slow connection to a remote machine. > | I can use X to connect to it, but I would prefer to: > | rxvt | ssh to the machine | emacs -nw > | And this works pretty well. But there is no mouse control. A quick version, you are doing a text-connection to the machine, and the normal text-terminals doesn't support mouse transfer. gpm sniffs the local mouse-port, not the remote terminals. /Andy > -- The eye of the beholder rests on the beauty! -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cannot use zlib with Mingw
On Sat, Dec 28, 2002 at 09:25:27PM +0100, [EMAIL PROTECTED] wrote:
>I was trying to compile a program which uses zlib with Mingw (i.e. with
>the flag -mno-cygwin) but the compilation failed because zlib.h could not
>be found. No problems with standard Cygwin compilation.
>
>Probably, if -mno-cygwin is used, only the directory /usr/include/mingw
>is searched, /usr/include is not. Well, the flag -I/usr/include could be
>added, but I am afraid some header files could conflict.
>
>To reproduce the problem: type this simple file
>
>#include
>
>int main(){
>return 0;
>}
>
>and compile it with
>
>gcc -c -mno-cygwin .c
>
>The error is "zlib.h: No such file or directory". No problems at all if
>
>gcc -c .c
>
>is launched)
>
>Is there a way to get round this problem?
www.mingw.org?
zlib.h is part of cygwin. Of course it can't be found if you say
-mno-cygwin. It seems like many people assume that -mno-cygwin is some
magical way to get all of cygwin's functionality without the use of the
cygwin dll. It isn't. The libraries in /usr/lib and the include files
in /usr/include are cygwin files. The files in /usr/lib/mingw and
/usr/include/mingw are provided for base mingw support. If you need
more or have more detailed mingw questions, then the mingw mailing list
is the place to go.
cgf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Cannot use zlib with Mingw
[EMAIL PROTECTED] wrote: > I was trying to compile a program which uses zlib with Mingw (i.e. > with the flag -mno-cygwin) but the compilation failed because zlib.h > could not be found. No problems with standard Cygwin compilation. > > Probably, if -mno-cygwin is used, only the directory > /usr/include/mingw is searched, /usr/include is not. Well, the flag > -I/usr/include could be added, but I am afraid some header files > could conflict. *Don't* do this. To get this to work, you will need to compile a Mingw zlib. Although Cygwin provides a minimal Mingw environment, *you cannot use libraries compiled for Cygwin in -mno-cygwin compilation*. Max. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
cat crashes with ctrl-backslash
Call cat with no parameter, press Ctrl-Backslash (or Ctrl-# with German keyboard), cat will crash. I can reproduce this crash 100% with the current version (2.0.21) of textutils and different versions of Cygwin. -- Huijing Zhou <[EMAIL PROTECTED]> CIP Computer Lab, Faculty of Economics University of Karlsruhe, Germany http://www2.wiwi.uni-karlsruhe.de -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Burning cygwin distribution CDs
Ross Smith II wrote: From: Laurynas Biveinis I want to burn CDs with full cygwin distribution with sources and so on. I've downloaded everything from ftp://ftp.gwdg.de/pub/linux/sources.redhat/cygwin/release, but it takes almost 1 GB. How should I burn it into 2 CDs so that setup.exe still works correctly? What directory layout should I use? Laurynas, I fit everything I need on 1 CD, by not including the /xfree directory (370MB), the /release/XFree86 directory (80MB), and not including the [prev] and [test] packages listed in setup.ini: Thank you, your script looks very handy in case of single CD. However this is not exactly what I need - I have to burn all the 1GB stuff to CDs. Laurynas -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cat crashes with ctrl-backslash
On Mon, Dec 30, 2002 at 12:08:59AM +0100, Huijing Zhou wrote: > Call cat with no parameter, press Ctrl-Backslash (or Ctrl-# with German > keyboard), cat will crash. I can reproduce this crash 100% with the > current version (2.0.21) of textutils and different versions of Cygwin. > Not surprising if, like my normal unix configuration, Ctrl-backslash is set with stty as your "quit" character. Similar to the "interupt" char (normally Ctrl-C) but also causes a core dump. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re:Strange behaviour of gcc
Danny,
Man! I scanned through the GCC man page for anything that would control
this action, and couldn't find anything. I don't see "-mno-stack-arg-probe"
listed there at all, nor is any option that includes the word "probe."
Google ("GCC mno-stack-arg-probe"
)
turns up only three relevant hits (including one recent thread on the
Cygwin mailing list:
and
).
Randall Schulz
At 12:28 2002-12-29, Danny Smith wrote:
> GCC's __builtin_alloca uses a helper function called _alloca to check
> the stack whenever allocating more that 4000 bytes in one go.
>
> Danny
To disable stack probing, add this switch -mno-stack-arg-probe.
Danny
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re:Strange behaviour of gcc
Hello Randall
Yeah, no documentation to speak of. The only reason I know about it because
I've been chasing the _alloca bug that Fish reported. It is still present in
GCC trunk (3.4). I have submitted a simple patch that fixes, but ... time for
a ping in the New Year.
Danny,
rrschulz wrote:
Man! I scanned through the GCC man page for anything that would control this
action, and couldn't find anything. I don't see "-mno-stack-arg-probe" listed
there at all, nor is any option that includes the word "probe."
Google ("GCC mno-stack-arg-probe"
)
turns up only three relevant hits (including one recent thread on the Cygwin
mailing list: and
).
Randall Schulz
http://movies.yahoo.com.au - Yahoo! Movies
- What's on at your local cinema?
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
system cpu 99% when doing ls -CFs on W2K laptop
Hi, It is stange that 'ls -CFs' takes forever on my laptop. I have to kill on tcsh window most of the time. The process which takes most of CPU is "System". I am using latest version of cygwin.dll. Following is my cygcheck output. Thanks. %cygcheck -s Cygwin Win95/NT Configuration Diagnostics Current System Time: Sun Dec 29 19:15:06 2002 Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 3 Path: c:\unix\bin c:\unix\usr\local\bin c:\home\xma\vim\src c:\unix\usr\X11R6\bin C C:\unix\java\j2se\bin C:\home\xma\java\ant\bin c:\java\jwsdp\bin c:\Oracle\Ora81\BIN c:\Oracle\Ora81\orb\bin c:\bv1to1\bin c:\bv1to1\orbix\bin c:\bea\wlserver6.1\bin c:\bc5\Bin c:\WINNT c:\WINNT\system32 c:\WINNT\system32\wbem c:\WINDOWS c:\WINDOWS\system32 c:\WINDOWS\system32\wbem c:\PROGRA~1\MICROS~3\Common\TOOLS\WINNT c:\PROGRA~1\MICROS~3\Common\TOOLS c:\PROGRA~1\MICROS~3\Common\msdev98\BIN c:\PROGRA~1\MICROS~3\VC98\Bin c:\PROGRA~1\INTERN~1 c:\atria\bin t:\triggers . SysDir: C:\WINNT\System32 WinDir: C:\WINNT CYGWIN = `nesec' HOME = `C:\home\xma' PWD = `/home/xma' TCL_LIBRARY = `C:\bv1to1cm\cm\lib\tcl' USER = `xma' Use `-r' to scan registry c: hd NTFS 11502Mb 73% CP CS UN PA FC d: cd N/AN/A C:\unix / system binmode C:\home /home system binmode C:\tmp /tmp system binmode C:\unix/bin /usr/bin system binmode C:\unix/lib /usr/lib system binmode ./ userbinmode,cygdrive Found: c:\unix\bin\bash.exe Found: c:\unix\bin\cat.exe Found: c:\unix\bin\cpp.exe Found: c:\unix\bin\find.exe Found: c:\unix\bin\gcc.exe Found: c:\unix\bin\gdb.exe Found: c:\unix\bin\ld.exe Found: c:\unix\bin\ls.exe Found: c:\unix\bin\make.exe Found: c:\unix\bin\sh.exe 58k 2002/05/07 c:\unix\bin\cygbz2-1.dll 54k 2002/01/27 c:\unix\bin\cygbz21.0.dll 6k 2002/06/24 c:\unix\bin\cygcharset-1.dll 644k 2002/12/08 c:\unix\bin\cygcrypto.dll 493k 2002/11/19 c:\unix\bin\cygcurl-2.dll 380k 2002/07/24 c:\unix\bin\cygdb-3.1.dll 326k 2002/06/26 c:\unix\bin\cygdb2.dll 487k 2002/07/24 c:\unix\bin\cygdb_cxx-3.1.dll 136k 2002/10/17 c:\unix\bin\cygexpat-0.dll 50k 2002/03/17 c:\unix\bin\cygexslt-0.dll 45k 2001/04/25 c:\unix\bin\cygform5.dll 35k 2002/01/09 c:\unix\bin\cygform6.dll 19k 2002/02/20 c:\unix\bin\cyggdbm.dll 490k 2002/09/21 c:\unix\bin\cygguile-12.dll 488k 2002/07/18 c:\unix\bin\cygguile-14.dll 63k 2002/07/18 c:\unix\bin\cygguile-srfi-srfi-13-14-1.dll 63k 2002/09/21 c:\unix\bin\cygguile-srfi-srfi-13-14-v-1-1.dll 24k 2002/07/18 c:\unix\bin\cygguile-srfi-srfi-4-1.dll 24k 2002/09/21 c:\unix\bin\cygguile-srfi-srfi-4-v-1-1.dll 14k 2002/07/18 c:\unix\bin\cygguilereadline-14.dll 14k 2002/09/21 c:\unix\bin\cygguilereadline-v-12-12.dll 17k 2001/06/28 c:\unix\bin\cyghistory4.dll 20k 2002/10/10 c:\unix\bin\cyghistory5.dll 306k 2002/04/27 c:\unix\bin\cyghttpd.dll 929k 2002/06/24 c:\unix\bin\cygiconv-2.dll 22k 2001/12/13 c:\unix\bin\cygintl-1.dll 28k 2002/09/20 c:\unix\bin\cygintl-2.dll 21k 2001/06/20 c:\unix\bin\cygintl.dll 45k 2002/02/08 c:\unix\bin\cygjbig1.dll 119k 2002/02/09 c:\unix\bin\cygjpeg6b.dll 59k 2002/09/20 c:\unix\bin\cygkpathsea-3-3-7.dll 25k 2002/07/16 c:\unix\bin\cygltdl-3.dll 26k 2001/04/25 c:\unix\bin\cygmenu5.dll 20k 2002/01/09 c:\unix\bin\cygmenu6.dll 156k 2001/04/25 c:\unix\bin\cygncurses++5.dll 175k 2002/01/09 c:\unix\bin\cygncurses++6.dll 226k 2001/04/25 c:\unix\bin\cygncurses5.dll 202k 2002/01/09 c:\unix\bin\cygncurses6.dll 15k 2001/04/25 c:\unix\bin\cygpanel5.dll 12k 2002/01/09 c:\unix\bin\cygpanel6.dll 40k 2001/11/21 c:\unix\bin\cygpcre.dll 39k 2001/11/21 c:\unix\bin\cygpcreposix.dll 175k 2002/07/22 c:\unix\bin\cygpng10.dll 179k 2002/07/22 c:\unix\bin\cygpng12.dll 170k 2002/01/21 c:\unix\bin\cygpng2.dll 22k 2002/06/09 c:\unix\bin\cygpopt-0.dll 108k 2001/06/28 c:\unix\bin\cygreadline4.dll 127k 2002/10/10 c:\unix\bin\cygreadline5.dll 165k 2002/12/08 c:\unix\bin\cygssl.dll 550k 2002/12/19 c:\unix\bin\cygtcl83.dll 12k 2002/12/19 c:\unix\bin\cygtclpip83.dll 253k 2002/02/10 c:\unix\bin\cygtiff3.dll 217k 2002/12/19 c:\unix\bin\cygtix4183.dll 830k 2002/12/19 c:\unix\bin\cygtk83.dll 25k 2002/07/14 c:\unix\bin\cygungif-4.dll 2689k 2002/11/16 c:\unix\bin\cygxerces-c21.dll 633k 2002/07/22 c:\unix\bin\cygxml2-2.dll 41k 2002/01/20 c:\unix\bin\cygXpm-noX4.dll 46k 2002/01/20 c:\unix\bin\cygXpm-X4.dll 152k 2002/03/17 c:\unix\bin\cygxslt-1.dll 15k 2002/03/17 c:\unix\bin\cygxsltbreakpoint-1.dll 50k 2002/03/12 c:\unix\bin\cygz.dll 880k 2002/12/25 c:\unix\bin\cygwin1.dll Cygwin DLL version info: DLL version: 1.3.18 DLL epoch: 19 DLL bad signal mask: 19005
Re: system cpu 99% when doing ls -CFs on W2K laptop
At 10:20 PM 12/29/2002, Xiangjiang Ma wrote: >Hi, > >It is stange that 'ls -CFs' takes forever on my >laptop. >I have to kill on tcsh window most of the time. >The process which takes most of CPU is "System". > >I am using latest version of cygwin.dll. >Following is my cygcheck output. > >Thanks. > >%cygcheck -s > >Cygwin Win95/NT Configuration Diagnostics >Current System Time: Sun Dec 29 19:15:06 2002 > >Windows 2000 Professional Ver 5.0 Build 2195 Service >Pack 3 > >Path: c:\unix\bin > c:\unix\usr\local\bin > c:\home\xma\vim\src > c:\unix\usr\X11R6\bin > C ^^^ Try getting rid of this. Larry Hall [EMAIL PROTECTED] RFK Partners, Inc. http://www.rfk.com 838 Washington Street (508) 893-9779 - RFK Office Holliston, MA 01746 (508) 893-9889 - FAX -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Hard links broken?
On Sun, Dec 29, 2002 at 10:32:40AM -0800, Randall R Schulz wrote:
> Nicolas,
>
> You've got something else going on. I, too, am running Cygwin 1.3.17
> ('cause of my other problems with 1.3.18) and hard links work fine for me.
I see that 1.3.18 just came out.
> I assume you are using an NTFS file system, right? FAT file systems don't
> support hard links.
Yes, NTFS, on XP. Er, no! That's the problem! I'd never bothered
checking (it's a single user laptop, used mostly for mutt/vim [and
Cygwin])), but the c: drive is FAT32 while the d: drive is NTFS (the
install disks give no partitioning or filesystem options either - it's
40%/60% FAT32/NTFS fot c:/d: - geez).
So, Cygwin must have been emulating hardlinks on FAT32 and that support
must now be gone. Geez.
Thanks, that about clears it up.
> I have noticed that Cygwin's link code falls back to copying for more
> reasons than just lack of support for hard links in the underlying file
> system. If I knew more about what variety of failures in attempting to
> create a hard link will cause Cygwin to fall back to copying the file, I'd
> tell you, but I just remember seeing other things do it.
Hmmm, I guess I could dig into the code... if I hadn't just figured it
out (see below).
> What are the ownership and permissions of the directory in which the files
> involved reside? How do they relate to the user (id) making the attempt?
CACLS complained that it works only on NTFS - that was the giveaway,
thanks. Hard links work just fine on the NTFS partition. Time to
convert c: to NTFS.
> Randall Schulz
>
> P.S. Nicolas, please subscribe to the list, at least for as long it takes
> to get this issue resolved.
No need anymore, thanks.
Cheers,
Nico
--
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Hard links broken?
Nicolas,
Whoa! You're jumping to conclusions. False conclusions.
Cygwin has always fallen back on a copy when a hard link was impossible.
All is as it was.
Randall Schulz
At 20:13 2002-12-29, Nicolas Williams wrote:
On Sun, Dec 29, 2002 at 10:32:40AM -0800, Randall R Schulz wrote:
> Nicolas,
>
> You've got something else going on. I, too, am running Cygwin 1.3.17
> ('cause of my other problems with 1.3.18) and hard links work fine for me.
I see that 1.3.18 just came out.
> I assume you are using an NTFS file system, right? FAT file systems don't
> support hard links.
Yes, NTFS, on XP. Er, no! That's the problem! I'd never bothered
checking (it's a single user laptop, used mostly for mutt/vim [and
Cygwin])), but the c: drive is FAT32 while the d: drive is NTFS (the
install disks give no partitioning or filesystem options either - it's
40%/60% FAT32/NTFS fot c:/d: - geez).
So, Cygwin must have been emulating hardlinks on FAT32 and that support
must now be gone. Geez.
Thanks, that about clears it up.
> I have noticed that Cygwin's link code falls back to copying for more
> reasons than just lack of support for hard links in the underlying file
> system. If I knew more about what variety of failures in attempting to
> create a hard link will cause Cygwin to fall back to copying the file, I'd
> tell you, but I just remember seeing other things do it.
Hmmm, I guess I could dig into the code... if I hadn't just figured it
out (see below).
> What are the ownership and permissions of the directory in which the files
> involved reside? How do they relate to the user (id) making the attempt?
CACLS complained that it works only on NTFS - that was the giveaway,
thanks. Hard links work just fine on the NTFS partition. Time to
convert c: to NTFS.
> Randall Schulz
>
> P.S. Nicolas, please subscribe to the list, at least for as long it takes
> to get this issue resolved.
No need anymore, thanks.
Cheers,
Nico
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Hard links broken?
On Sun, Dec 29, 2002 at 10:13:48PM -0600, Nicolas Williams wrote:
>On Sun, Dec 29, 2002 at 10:32:40AM -0800, Randall R Schulz wrote:
>> Nicolas,
>>
>> You've got something else going on. I, too, am running Cygwin 1.3.17
>> ('cause of my other problems with 1.3.18) and hard links work fine for me.
>
>I see that 1.3.18 just came out.
>
>> I assume you are using an NTFS file system, right? FAT file systems don't
>> support hard links.
>
>Yes, NTFS, on XP. Er, no! That's the problem! I'd never bothered
>checking (it's a single user laptop, used mostly for mutt/vim [and
>Cygwin])), but the c: drive is FAT32 while the d: drive is NTFS (the
>install disks give no partitioning or filesystem options either - it's
>40%/60% FAT32/NTFS fot c:/d: - geez).
>
>So, Cygwin must have been emulating hardlinks on FAT32 and that support
>must now be gone. Geez.
If such a change had been made it would have been advertised and you
would have seen or been able to find an announcement about it.
Cygwin has never emulated hard links on FAT*. Or at least it hasn't
during the last five years that I've been paying attention to such
things.
cgf
--
Please use the resources at cygwin.com rather than sending personal email.
Special for spam email harvesters: send email to [EMAIL PROTECTED]
and be permanently blocked from mailing lists at sources.redhat.com
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: system cpu 99% when doing ls -CFs on W2K laptop
Larry, Thank you for your help, but I still had the same problem after hacking pATH. I prepared a simplies PATH, and could still reproduced the problem. The interested thing is that it seems only happened in /tmp directory, and it happened mostly the 2nd time after I did 'ls -s'. cd /c/ ls (always okay) ls -s (always okay) ls -s (always okay) cd /tmp ls (always okay) ls (always okay) ls -s (okay most of times) ls -s (System CPU 100%, cannot stop by Ctrl-C) Any clue. PS: cygcheck -s Cygwin Win95/NT Configuration Diagnostics Current System Time: Sun Dec 29 20:52:55 2002 Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 3 Path: c:\unix\bin SysDir: C:\WINNT\System32 WinDir: C:\WINNT CYGWIN = `nesec' HOME = `C:\home\xma' PWD = `/home/xma' TCL_LIBRARY = `C:\bv1to1cm\cm\lib\tcl' USER = `xma' Use `-r' to scan registry c: hd NTFS 11502Mb 73% CP CS UN PA FC d: cd N/AN/A C:\unix / system binmode C:\home /home system binmode C:\tmp /tmp system binmode C:\unix/bin /usr/bin system binmode C:\unix/lib /usr/lib system binmode ./ userbinmode,cygdrive Found: c:\unix\bin\bash.exe Found: c:\unix\bin\cat.exe Found: c:\unix\bin\cpp.exe Found: c:\unix\bin\find.exe Found: c:\unix\bin\gcc.exe Found: c:\unix\bin\gdb.exe Found: c:\unix\bin\ld.exe Found: c:\unix\bin\ls.exe Found: c:\unix\bin\make.exe Found: c:\unix\bin\sh.exe 58k 2002/05/07 c:\unix\bin\cygbz2-1.dll 54k 2002/01/27 c:\unix\bin\cygbz21.0.dll 6k 2002/06/24 c:\unix\bin\cygcharset-1.dll 644k 2002/12/08 c:\unix\bin\cygcrypto.dll 493k 2002/11/19 c:\unix\bin\cygcurl-2.dll 380k 2002/07/24 c:\unix\bin\cygdb-3.1.dll 326k 2002/06/26 c:\unix\bin\cygdb2.dll 487k 2002/07/24 c:\unix\bin\cygdb_cxx-3.1.dll 136k 2002/10/17 c:\unix\bin\cygexpat-0.dll 50k 2002/03/17 c:\unix\bin\cygexslt-0.dll 45k 2001/04/25 c:\unix\bin\cygform5.dll 35k 2002/01/09 c:\unix\bin\cygform6.dll 19k 2002/02/20 c:\unix\bin\cyggdbm.dll 490k 2002/09/21 c:\unix\bin\cygguile-12.dll 488k 2002/07/18 c:\unix\bin\cygguile-14.dll 63k 2002/07/18 c:\unix\bin\cygguile-srfi-srfi-13-14-1.dll 63k 2002/09/21 c:\unix\bin\cygguile-srfi-srfi-13-14-v-1-1.dll 24k 2002/07/18 c:\unix\bin\cygguile-srfi-srfi-4-1.dll 24k 2002/09/21 c:\unix\bin\cygguile-srfi-srfi-4-v-1-1.dll 14k 2002/07/18 c:\unix\bin\cygguilereadline-14.dll 14k 2002/09/21 c:\unix\bin\cygguilereadline-v-12-12.dll 17k 2001/06/28 c:\unix\bin\cyghistory4.dll 20k 2002/10/10 c:\unix\bin\cyghistory5.dll 306k 2002/04/27 c:\unix\bin\cyghttpd.dll 929k 2002/06/24 c:\unix\bin\cygiconv-2.dll 22k 2001/12/13 c:\unix\bin\cygintl-1.dll 28k 2002/09/20 c:\unix\bin\cygintl-2.dll 21k 2001/06/20 c:\unix\bin\cygintl.dll 45k 2002/02/08 c:\unix\bin\cygjbig1.dll 119k 2002/02/09 c:\unix\bin\cygjpeg6b.dll 59k 2002/09/20 c:\unix\bin\cygkpathsea-3-3-7.dll 25k 2002/07/16 c:\unix\bin\cygltdl-3.dll 26k 2001/04/25 c:\unix\bin\cygmenu5.dll 20k 2002/01/09 c:\unix\bin\cygmenu6.dll 156k 2001/04/25 c:\unix\bin\cygncurses++5.dll 175k 2002/01/09 c:\unix\bin\cygncurses++6.dll 226k 2001/04/25 c:\unix\bin\cygncurses5.dll 202k 2002/01/09 c:\unix\bin\cygncurses6.dll 15k 2001/04/25 c:\unix\bin\cygpanel5.dll 12k 2002/01/09 c:\unix\bin\cygpanel6.dll 40k 2001/11/21 c:\unix\bin\cygpcre.dll 39k 2001/11/21 c:\unix\bin\cygpcreposix.dll 175k 2002/07/22 c:\unix\bin\cygpng10.dll 179k 2002/07/22 c:\unix\bin\cygpng12.dll 170k 2002/01/21 c:\unix\bin\cygpng2.dll 22k 2002/06/09 c:\unix\bin\cygpopt-0.dll 108k 2001/06/28 c:\unix\bin\cygreadline4.dll 127k 2002/10/10 c:\unix\bin\cygreadline5.dll 165k 2002/12/08 c:\unix\bin\cygssl.dll 550k 2002/12/19 c:\unix\bin\cygtcl83.dll 12k 2002/12/19 c:\unix\bin\cygtclpip83.dll 253k 2002/02/10 c:\unix\bin\cygtiff3.dll 217k 2002/12/19 c:\unix\bin\cygtix4183.dll 830k 2002/12/19 c:\unix\bin\cygtk83.dll 25k 2002/07/14 c:\unix\bin\cygungif-4.dll 2689k 2002/11/16 c:\unix\bin\cygxerces-c21.dll 633k 2002/07/22 c:\unix\bin\cygxml2-2.dll 41k 2002/01/20 c:\unix\bin\cygXpm-noX4.dll 46k 2002/01/20 c:\unix\bin\cygXpm-X4.dll 152k 2002/03/17 c:\unix\bin\cygxslt-1.dll 15k 2002/03/17 c:\unix\bin\cygxsltbreakpoint-1.dll 50k 2002/03/12 c:\unix\bin\cygz.dll 880k 2002/12/25 c:\unix\bin\cygwin1.dll Cygwin DLL version info: DLL version: 1.3.18 DLL epoch: 19 DLL bad signal mask: 19005 DLL old termios: 5 DLL malloc env: 28 API major: 0 API minor: 69 Shared data: 3 DLL identifier: cygwin1 Mount registry: 2 Cygnus registry name: Cygnus Solutions Cygwin registry name: Cygwin Program options name: Program Options Cygwin mount registry name: mounts v2 Cygdrive flags: cygdrive flags Cygdrive prefix: cygdrive prefix Cygdrive default prefix: Build date: Wed Dec 25 15:37:50 EST 2002
Re: system cpu 99% when doing ls -CFs on W2K laptop
--- Xiangjiang Ma <[EMAIL PROTECTED]> wrote: > > ... > >cd /c/ >ls (always okay) >ls -s (always okay) >ls -s (always okay) >cd /tmp >ls (always okay) >ls (always okay) >ls -s (okay most of times) >ls -s (System CPU 100%, cannot stop by Ctrl-C) > >Any clue. > >... > >CYGWIN = `nesec' Should ne ntsec. Try changing this in either your cygwin.bat or the system environment. > >... > >__ >Do you Yahoo!? >Yahoo! Mail Plus - Powerful. Affordable. Sign up now. >http://mailplus.yahoo.com > >-- >Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple >Bug reporting: http://cygwin.com/bugs.html >Documentation: http://cygwin.com/docs.html >FAQ: http://cygwin.com/faq/ Elfyn [EMAIL PROTECTED] _ www.smokeJet.com - Free UK Internet Services _ Select your own custom email address for FREE! Get [EMAIL PROTECTED] w/No Ads, 6MB, POP & more! http://www.everyone.net/selectmail?campaign=tag -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
mips-tx49-elf-gcc
Hi, I'm currently developing some application on TOSHIBA's tx49. I'm using cygwin as my development tool. But I couldnt find the patch for the tx49 cross compiler. Can please some one advise me on where to look for this patch? Regards, Rajesh. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: system cpu 99% when doing ls -CFs on W2K laptop
No, I comment CYGWIN out, and problem persistant. I even tried to using "true" ls.exe without usin cygwin.dll, and CPU still kept growing when doing "ls -s" under /tmp. I guess /tmp cannot be used at all. Any more hint? Thanks. __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: system cpu 99% when doing ls -CFs on W2K laptop
When you say "true" ls.exe what do you mean? If your talking about the one that came with cygwin, stock ls, then it's going to use the cygwin1.dll. I tried your "testcase" and did it so much my bash history is at 1039. All worked perfectly. I don't suppose you have some *large files* in your /tmp directoy do you? Perhaps over the 2GB limit? Elfyn [EMAIL PROTECTED] --- Xiangjiang Ma <[EMAIL PROTECTED]> wrote: > >No, I comment CYGWIN out, and problem persistant. > >I even tried to using "true" ls.exe without usin >cygwin.dll, >and CPU still kept growing when doing "ls -s" under >/tmp. > >I guess /tmp cannot be used at all. > >Any more hint? > >Thanks. > > > >__ >Do you Yahoo!? >Yahoo! Mail Plus - Powerful. Affordable. Sign up now. >http://mailplus.yahoo.com > >-- >Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple >Bug reporting: http://cygwin.com/bugs.html >Documentation: http://cygwin.com/docs.html >FAQ: http://cygwin.com/faq/ _ www.smokeJet.com - Free UK Internet Services _ Select your own custom email address for FREE! Get [EMAIL PROTECTED] w/No Ads, 6MB, POP & more! http://www.everyone.net/selectmail?campaign=tag -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
