set - unset not working
Hi Team, i have installed the latest version of the CYgwin ( 1.7 ) , for the build activities of the NT builds. i am not able to set/unset env variables. every time the following error pops up : set/unset not recognized as internal or external command. i have latest bash installed. i am not able to find the set/unset exe in the cygwin\bin folder. please help. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: sqlite defect
On 2013-07-18 PM 5:59, Corinna Vinschen wrote:> On Jul 18 17:11,
jojelino wrote:
>> On 2013-07-18 AM 10:53, Warren Young wrote:
>>> Nothing so simple. Locking is handled at the OS and/or Cygwin DLL
>>> level. The build change between 3.7.16.2 and 3.7.17-3 is that
we're now
>>> relying on new features in the Cygwin DLL to do Windows-style
locking by
>>> default.
>>>
>>> Older versions of Cygwin SQLite bypassed the Cygwin DLL entirely for
>>> this, going straight to the Win32 API, thereby preventing the DLL from
>>> interposing itself for the "posix" case.
>>>
>> Mandatory locking feature of cygwin used in sqlite is broken.
>
> Simple testcase in plain C?
>
>
> Corinna
>
#include
#include
#include
#include
#include
int
main()
{
int fd = open("asdf.txt", O_BINARY | O_RDWR | O_NOINHERIT | O_CREAT);
const char* buf =
"K\0";
int i=0;
write(fd, buf, strlen(buf));
fcntl(fd,F_LCK_MANDATORY,0);
assert(flock(fd,F_SETOWN)==0);
assert(flock(fd,F_SETOWN)==0);
assert(flock(fd,LOCK_NB|LOCK_UN)==0);
fcntl(fd,F_LCK_MANDATORY,1);
assert(flock(fd,F_SETOWN)==0);
assert(flock(fd,LOCK_NB|LOCK_UN)==0);
assert(flock(fd,F_SETOWN)==0);
assert(flock(fd,F_SETOWN)==0); /* assertion "flock(fd,F_SETOWN)==0"
failed: file "f_lck.c", line 28, function: main */
return 0;
}
/**/
--
Regards.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Mingw build problem for TCL
Hi, sorry if this isn't the correct place. I have previously used the mingw-* packages to create a Windows compile of tcl8.6.0, but currently it doesn't work. It compiles without error as far as I can see, but when you try to run the executable (tclsh8.6.0.exe) it returns immediately with code 127. (PS ... I have tried it with the current mingw/msys system directly, and that compiles OK.) --- $ uname -a CYGWIN_NT-6.1-WOW64 jon-Z930 1.7.21(0.267/5/3) 2013-07-15 12:17 i686 Cygwin $ cygcheck -c | fgrep mingw mingw-binutils 2.23.1-1 OK mingw-gcc-core 4.7.3-1 OK mingw-gcc-g++4.7.3-1 OK mingw-pthreads 20110507-2 OK mingw-runtime4.0-1OK mingw-w32api 4.0-1OK $ ./configure --host=i686-pc-mingw32 --build=i686-pc-mingw32 --prefix=/Tcl ... cut ... $ make binaries ... cut ... i686-pc-mingw32-gcc -O2 -fomit-frame-pointer -DUNICODE -D_UNICODE tclAppInit.o libtcl86.a libtclstub86.a -lnetapi32 -lkernel32 -luser32 -ladvapi32 -lws2_32 /cygdrive/c/src/tcl8.6.0/compat/zlib/win32/zdll.lib \ tclsh.res.o -o tclsh86.exe -mconsole -pipe $ echo $? 0 $ ./tclsh86.exe $ echo $? 127 -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: confirm subscribe to cygwin-developers-dig...@cygwin.com
[What an odd subject line] On Thu, Jul 18, 2013 at 04:23:32PM +0100, trefor.2.edwa...@bt.com wrote: >I have a very recent version of Cygwin and using the SIPP application. >This calls nanosleep from within a thread. "Very recent" is not a precise enough distinction for debugging problems. See: http://cygwin.com/problems.html . >Effectively , every second, the application > >* Creates a thread > >* Calls nanosleep 9 times. > >* Deletes the thread > >And every second, according to windows task manager, it one more handle >is being used. Eventually it runs out of resources and crashes. Seems like a simple test case would show this. Please provide one. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: confirm subscribe to cygwin-developers-dig...@cygwin.com
I have a very recent version of Cygwin and using the SIPP application. This calls nanosleep from within a thread. Effectively , every second, the application * Creates a thread * Calls nanosleep 9 times. * Deletes the thread And every second, according to windows task manager, it one more handle is being used. Eventually it runs out of resources and crashes. If I comment out the call to nanosleep, the number of handles stay steady. If the problem was just within nanosleep, the I would expect it to "leak" 9 handles every second, but it only one is leaked. So I'm assuming that it somehow. It's a combination of the thread and the calls to nanosleep. Hence my question, is nanosleep thread safe? Regards Trefor Edwards -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: how to create symlink in linux file server from windows using cygwin
On Jul 18 16:15, Divakar K wrote: > Hi Guys, > > i dont know why ln is not working. > > this is what i did. > > C:\Users\test1>pushd > \\ostorenas\odi\ostore_platform_logs\ostore\7.4.0\test1\linux64 > > Z:\ostore_platform_logs\ostore\7.4.0\test1\linux64>c:\cygwin\bin\ln -s > diva_test LATEST > > in the above line "diva_test" is a folder. > > it is created a new file as "LATEST". not as symlink. > > drwxr-xr-x 2 test1 rdl 4096 Jul 18 05:26 diva_test > -rw-r--r-- 1 test1 rdl 32 Jul 18 2013 LATEST > > or is there any other way to create symlink? or any other command. for > e.g., windows mklink command? The Samba server must support storage of DOS attributes. See `man smb.conf' for how to configure this. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
how to create symlink in linux file server from windows using cygwin
Hi Guys, i dont know why ln is not working. this is what i did. C:\Users\test1>pushd \\ostorenas\odi\ostore_platform_logs\ostore\7.4.0\test1\linux64 Z:\ostore_platform_logs\ostore\7.4.0\test1\linux64>c:\cygwin\bin\ln -s diva_test LATEST in the above line "diva_test" is a folder. it is created a new file as "LATEST". not as symlink. drwxr-xr-x 2 test1 rdl 4096 Jul 18 05:26 diva_test -rw-r--r-- 1 test1 rdl 32 Jul 18 2013 LATEST or is there any other way to create symlink? or any other command. for e.g., windows mklink command? Can someone please help? Thanks & Regards, Divakar -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 1.7.21: Problem using svn accessing UNC network pathes
On Jul 18 11:38, Roland Schwingel wrote: > Hi... > > Today I updated my cygwin to version 1.7.21. Due to a bunch of > lockup problems I was previously sticking to 1.7.17. A short test > shows that the lockups appears to be solved (that are the good news > - thanks to all involved) - but I got a new problem now. Performing > a "svn st" on a subversion working copy residing on a UNC share is > broken now. > > I do get this error message: > svn: E078: Can't read directory '//server/share/path': Partial > results are valid but processing is incomplete. > > When I exchange cygwin1.dll with the one from 1.7.20 the svn st > command works as expected. > > So I did an strace with both cygwin1.dll versions (I attached the > outputs of both runs to this email in a tarball). > > svn_st_1720.txt contains the working trace when doing svn st on 1.7.20 > svn_st_1721.txt contains the output of my broken run on 1.7.21 > > The output is pretty much in sync up to line 824. It starts to differ > heavily in 825. In line 825 of svn_st_1721.txt it appears that maybe > in normalize_posix_path() a / too much is cut off from the beginning > of the unc path and it might mess up local and network pathes. > > BTW: I still have to run a self compiled version subversion 1.7.2 as > you can see from the strace logs. I recompiled it today freshly on > 1.7.21 but this does not make any change. > > Thanks for your help, Bug in the new code recognizing invalid path preceeding a ".." path component. It ignores one leading slash in case of UNC paths and so accidentally checks for /server/share/path rather than //server/share/path. I fixed that in CVS and I just generated new x86 and x86_64 snapshots. Please take your pick at http://cygwin.com/snapshots/ and report back if you still see problems with it. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: sqlite defect
On Jul 18 17:11, jojelino wrote: > On 2013-07-18 AM 10:53, Warren Young wrote: > >Nothing so simple. Locking is handled at the OS and/or Cygwin DLL > >level. The build change between 3.7.16.2 and 3.7.17-3 is that we're now > >relying on new features in the Cygwin DLL to do Windows-style locking by > >default. > > > >Older versions of Cygwin SQLite bypassed the Cygwin DLL entirely for > >this, going straight to the Win32 API, thereby preventing the DLL from > >interposing itself for the "posix" case. > > > Mandatory locking feature of cygwin used in sqlite is broken. Simple testcase in plain C? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: sqlite defect
On 2013-07-18 AM 10:53, Warren Young wrote: Nothing so simple. Locking is handled at the OS and/or Cygwin DLL level. The build change between 3.7.16.2 and 3.7.17-3 is that we're now relying on new features in the Cygwin DLL to do Windows-style locking by default. Older versions of Cygwin SQLite bypassed the Cygwin DLL entirely for this, going straight to the Win32 API, thereby preventing the DLL from interposing itself for the "posix" case. Mandatory locking feature of cygwin used in sqlite is broken. Just build plain sqlite build without the cygport patch that led the disaster. unless you have familiar with exotic adventure like finding undocumented behavior of windows wasting many man-hours to workaround the problem. -- Regards. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: bzr problem
Solved. What I've done was the clean install[1]. But I don't know what did the trick nor the cause of the problem[2] after all. Performing rebaseall doesn't seem to do any harm in this installation. Regards, [1] Rename c:\cygwin\ to c:\cygwin_old\ Install Cygwin in c:\cygwin\ using setup.exe Copy /usr/local and /home stuff from cygwin_old to cygwin [2] http://thread.gmane.org/gmane.os.cygwin/140753 -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
