can modify file on network drive, but cannot create files
Hi Cygwiners, I need a hint. The network drive (\server\) is mounted as H:\. Cygwin can access files on H drive; can modify/delete files on H drive; however, it cannot create files. The program says permission denied. Do I need to write some configuration files? Xianwen -- Backup email: v...@dr.com -- 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: can modify file on network drive, but cannot create files
Hi Cygwiners, I need a hint. The network drive (\server\) is mounted as H:\. Cygwin can access files on H drive; can modify/delete files on H drive; however, it cannot create files. The program says permission denied. Do I need to write some configuration files? Xianwen What kind of network file system is it? Assuming a Unix-like permission system, it is quite surprising that you can delete files but not create any. Or maybe you can delete (and create) files in a subdirectory but not create (and delete) in the root directory H:\? Otherwise it might be due to some unusual ACL settings on the remote side, or maybe you have exceeded your quota (amount of allowed capacity) on the remote server? Ask the administrator. -- Thomas -- 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: can modify file on network drive, but cannot create files
Hi Thomas, Thanks a lot for your email! The remote server runs Windows Server 2008 R2 Enterprise. I have not exceeded the quota. Cygwin cannot delete files on H in both root and sub directories. Xianwen On Wed, May 11, 2011 at 9:22 AM, Xianwen Chen wrote: > Hi Thomas, > > Thanks a lot for your email! > > The remote server runs Windows Server 2008 R2 Enterprise. > > I have not exceeded the quota. > > Cygwin cannot delete files on H in both root and sub directories. > > Xianwen > > On Wed, May 11, 2011 at 9:12 AM, Thomas Wolff wrote: >> >>> Hi Cygwiners, >>> >>> I need a hint. >>> >>> The network drive (\server\) is mounted as H:\. >>> >>> Cygwin can access files on H drive; can modify/delete files on H >>> drive; however, it cannot create files. The program says permission >>> denied. >>> >>> Do I need to write some configuration files? >>> >>> Xianwen >> >> What kind of network file system is it? >> Assuming a Unix-like permission system, it is quite surprising that you can >> delete files but not create any. >> Or maybe you can delete (and create) files in a subdirectory but not create >> (and delete) in the root directory H:\? >> Otherwise it might be due to some unusual ACL settings on the remote side, >> or maybe you have exceeded your quota (amount of allowed capacity) on the >> remote server? Ask the administrator. >> -- >> Thomas >> >> -- >> 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 >> >> > > > > -- > Backup email: xianwen.c...@gmail.com > -- Backup email: v...@dr.com -- 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: can modify file on network drive, but cannot create files
Hi Thomas, Thanks a lot for your email! The remote server runs Windows Server 2008 R2 Enterprise. I have not exceeded the quota. Cygwin cannot delete files on H in both root and sub directories. Xianwen On Wed, May 11, 2011 at 9:12 AM, Thomas Wolff wrote: > >> Hi Cygwiners, >> >> I need a hint. >> >> The network drive (\server\) is mounted as H:\. >> >> Cygwin can access files on H drive; can modify/delete files on H >> drive; however, it cannot create files. The program says permission >> denied. >> >> Do I need to write some configuration files? >> >> Xianwen > > What kind of network file system is it? > Assuming a Unix-like permission system, it is quite surprising that you can > delete files but not create any. > Or maybe you can delete (and create) files in a subdirectory but not create > (and delete) in the root directory H:\? > Otherwise it might be due to some unusual ACL settings on the remote side, > or maybe you have exceeded your quota (amount of allowed capacity) on the > remote server? Ask the administrator. > -- > Thomas > > -- > 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 > > -- Backup email: xianwen.c...@gmail.com -- 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: can modify file on network drive, but cannot create files
Hi Thomas, Thanks a lot for your email! The remote server runs Windows Server 2008 R2 Enterprise. I have not exceeded the quota. Cygwin cannot delete files on H in both root and sub directories. Xianwen OK, in your first message you wrote you can delete but not create files which would have been strange. That you can neither delete nor create files (but still existing files) is actually more normal (in terms of Unix-like permission). Just check the permissions of the directory, they should include write access for you. If you are the owner, you can easily change that with chmod +w /cygdrive/h. If you are not the owner of your own network directory, ask your server administrator to fix that. -- Thomas On Wed, May 11, 2011 at 9:12 AM, Thomas Wolff wrote: Hi Cygwiners, I need a hint. The network drive (\server\) is mounted as H:\. Cygwin can access files on H drive; can modify/delete files on H drive; however, it cannot create files. The program says permission denied. Do I need to write some configuration files? Xianwen What kind of network file system is it? Assuming a Unix-like permission system, it is quite surprising that you can delete files but not create any. Or maybe you can delete (and create) files in a subdirectory but not create (and delete) in the root directory H:\? Otherwise it might be due to some unusual ACL settings on the remote side, or maybe you have exceeded your quota (amount of allowed capacity) on the remote server? Ask the administrator. -- Thomas -- 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 -- 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: GNU screen on Cygwin: Cannot seem to reattach, no matter what I try
On May 10 15:07, Andrew Schulman wrote: > > a session that I detached on the same tty just seconds before. > > > > 3. chmod 666 on the socket file did not work (its permissions were > > already 644, owned my 'morse', as shown in my original session long). > > No, I suggested that you try 0600, on the theory that your 0640 permissions > might be too permissive, and screen would refuse to use the socket. > Unlikely, but worth a try. > > However, if your socket is on a FAT file system, I don't know if you can > set 0600 permissions. > > > HOWEVER, I am wondering: my Cygin /tmp *IS* on a FAT32 filesystem, *NOT* > > an NTFS filesystem. Would that matter? Are socket files properly > > handled by Cygwin on FAT32? (I've never used a socket-based Cygwin > > program on this host before, at least not to my knowledge.) > > Hm, that could explain it. I don't recall this coming up before. AF_LOCAL/AF_UNIX sockets are handled on all file systems. But FAT/FAT32 have no provisions to store permissions like NTFS has. Therefore the POSIX permission bits are only faked, 0755 for directories, 0755 for files with the suffixes .exe, .lnk., and .com, 0644 otherwise. If you chmod -r a file you get 0555 for .exe etc, or 0444 otherwise. You can probably live with this if you can do without permissions on files, but here's one of the cases where the application apparently checks for permissions. Same goes for many other security sensitive applications. My unofficial, very personal recommendation: Don't use FAT/FAT32 unless you really have to, for instance on USB sticks shared with embedded gear. Otherwise FAT/FAT32 is a crappy, unsecure, space-wasting file system about as modern as the roman empire. And you know, what have the romans ever done for us? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader 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: can modify file on network drive, but cannot create files
Hi Thomas, Thanks a lot! On Wed, May 11, 2011 at 9:33 AM, Thomas Wolff wrote: > > OK, in your first message you wrote you can delete but not create files > which would have been strange. I'm sorry that my bad command of English confused you. This is what I wanted to say: Cygwin can modify and delete, but not create files. > That you can neither delete nor create files (but still existing files) is > actually more normal (in terms of Unix-like permission). > Just check the permissions of the directory, they should include write > access for you. If you are the owner, you can easily change that with chmod $ chmod +w /cygdrive/h/Temp chmod: changing permission of 'Temp': Permission denied. Thanks to your hint, I went on investigating: $ ls -l /cygdrive/h/ -rwx--+ 1 myusername mkpasswd 0 May 10 22:19 Temp I think the problem lies in the mkpasswd part of the ownership. In UNIX, mkpasswd would be the owner group of the folder. How about in Windows? > +w /cygdrive/h. If you are not the owner of your own network directory, ask > your server administrator to fix that. Yes, I think I have to talk to him about it. ;) Xianwen > -- > Thomas > >> On Wed, May 11, 2011 at 9:12 AM, Thomas Wolff wrote: Hi Cygwiners, I need a hint. The network drive (\server\) is mounted as H:\. Cygwin can access files on H drive; can modify/delete files on H drive; however, it cannot create files. The program says permission denied. Do I need to write some configuration files? Xianwen >>> >>> What kind of network file system is it? >>> Assuming a Unix-like permission system, it is quite surprising that you >>> can >>> delete files but not create any. >>> Or maybe you can delete (and create) files in a subdirectory but not >>> create >>> (and delete) in the root directory H:\? >>> Otherwise it might be due to some unusual ACL settings on the remote >>> side, >>> or maybe you have exceeded your quota (amount of allowed capacity) on the >>> remote server? Ask the administrator. >>> -- >>> Thomas >>> >>> -- >>> 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 >>> >>> >> >> > > > -- > 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 > > -- Backup email: v...@dr.com -- 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: GNU screen on Cygwin: Cannot seem to reattach, no matter what I try
On May 11 09:34, Corinna Vinschen wrote: > On May 10 15:07, Andrew Schulman wrote: > > > a session that I detached on the same tty just seconds before. > > > > > > 3. chmod 666 on the socket file did not work (its permissions were > > > already 644, owned my 'morse', as shown in my original session long). > > > > No, I suggested that you try 0600, on the theory that your 0640 permissions > > might be too permissive, and screen would refuse to use the socket. > > Unlikely, but worth a try. > > > > However, if your socket is on a FAT file system, I don't know if you can > > set 0600 permissions. > > > > > HOWEVER, I am wondering: my Cygin /tmp *IS* on a FAT32 filesystem, *NOT* > > > an NTFS filesystem. Would that matter? Are socket files properly > > > handled by Cygwin on FAT32? (I've never used a socket-based Cygwin > > > program on this host before, at least not to my knowledge.) > > > > Hm, that could explain it. I don't recall this coming up before. > > AF_LOCAL/AF_UNIX sockets are handled on all file systems. Correction: AF_LOCAL/AF_UNIX sockets are handled on all file systems which support DOS attributes. They don't work on NFS, for instance. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader 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: Who's using "CYGWIN=tty" and why?
On Wed, May 11, 2011 at 18:34, Corinna Vinschen wrote: > On May 10 17:17, Len Giambrone wrote: >> We use windows native jam which spawns any number of cmd, cygwin, or studio >> processes. >> If we spawn it from a Cygwin terminal that doesn't have CYGWIN=tty set, we >> get: > > I assume that most people, like me, don't even know what jam is. At the risk of confusing the issue if I'm mistaken: jam - "Just Another Make" http://www.perforce.com/jam/jam.html -- David. -- 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 use windres.exe without installing cygwin?
Hi Corinna, thanks for your answer. Of course I'm aware of GPL. I'll provide it with source code. >You can't. Windres is a Cygwin tool using the Cygwin DLL. Gcc is a >Cygwin tool using the Cygwin DLL. Either you provide *all* the stuff >required to run the script (and don't forget to provide the sources as >well), or you let the user install Cygwin via setup.exe. This is the >preferred method anyway. How can I find "the stuff required to run the script"? Even if I copy all files to another computer it does not work. (I set proper PATH, of course.) Is there any other stuff that cygwin requires and where can I find it? Tetsuya -- View this message in context: http://old.nabble.com/how-to-use-windres.exe-without-installing-cygwin--tp31586006p31592937.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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 use windres.exe without installing cygwin?
Hi Chuck, Charles Wilson-2 wrote: > > Well, OUR windres is a cygwin tool. You can, of course, use the > mingw.org or mingw64.sf version of windres. They each have their own > list(s) of dependencies, but cygwin1.dll is not one of them. > Thanks for tips. If I can't make to work my script with cygwin, I will try with mingw version windres. -- Tetsuya -- View this message in context: http://old.nabble.com/how-to-use-windres.exe-without-installing-cygwin--tp31586006p31592961.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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
ssh - Could not create directory 'c/.ssh'.
Hi I have happily used Cygwin ssh from "DOS" command prompt for many years but on upgrading to V1.7 get this error message. Further info: OS: Vista /etc/passwd line: tda:unused_by_nt/2000/xp:1000:513:U-laptop1\tda,S-1-5-21-2414507100-3802266639-3593817948-1000:/home/tda:/bin/bash The interesting thing is that if I open up a second command prompt and run an arbitrary cygwin command (like "less filename"). ssh successfully finds /home/tda/.ssh (but only for so long as that second command is running). I suspect this is something to do with the changes to mounts, but so far I've been unable to find a fix. Thanks Tim -- 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: GNU screen on Cygwin: Cannot seem to reattach, no matter what I try
> On May 10 15:07, Andrew Schulman wrote: > > > a session that I detached on the same tty just seconds before. > > > > > > 3. chmod 666 on the socket file did not work (its permissions were > > > already 644, owned my 'morse', as shown in my original session long). > > > > No, I suggested that you try 0600, on the theory that your 0640 permissions > > might be too permissive, and screen would refuse to use the socket. > > Unlikely, but worth a try. > > > > However, if your socket is on a FAT file system, I don't know if you can > > set 0600 permissions. > > > > > HOWEVER, I am wondering: my Cygin /tmp *IS* on a FAT32 filesystem, *NOT* > > > an NTFS filesystem. Would that matter? Are socket files properly > > > handled by Cygwin on FAT32? (I've never used a socket-based Cygwin > > > program on this host before, at least not to my knowledge.) > > > > Hm, that could explain it. I don't recall this coming up before. > > AF_LOCAL/AF_UNIX sockets are handled on all file systems. > > But FAT/FAT32 have no provisions to store permissions like NTFS has. > Therefore the POSIX permission bits are only faked, 0755 for > directories, 0755 for files with the suffixes .exe, .lnk., and .com, > 0644 otherwise. If you chmod -r a file you get 0555 for .exe etc, or > 0444 otherwise. > > You can probably live with this if you can do without permissions on > files, but here's one of the cases where the application apparently > checks for permissions. Same goes for many other security sensitive > applications. > > My unofficial, very personal recommendation: Don't use FAT/FAT32 unless > you really have to, for instance on USB sticks shared with embedded > gear. Otherwise FAT/FAT32 is a crappy, unsecure, space-wasting file > system about as modern as the roman empire. And you know, what have > the romans ever done for us? They left some pretty great ruins, I was climbing on 'em 2 weeks ago. But that's not much of a model for Cygwin. My dim recollection is that screen will refuse to reattach to a socket whose permissions are too loose. Of course if that's the problem here, then (1) screen created the socket but then didn't bother to check that the right permissions had been set on it; and (2) it gave a completely unhelpful error message when it refused to reattach. Both of those are possible and I could probably fix them in a spare hour or two. So, it seems that my suggestion #2 is the one to try. -- 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: ssh - Could not create directory 'c/.ssh'.
On 5/11/2011 6:44 AM, Tim Allen wrote: Hi I have happily used Cygwin ssh from "DOS" command prompt for many years but on upgrading to V1.7 get this error message. Further info: OS: Vista /etc/passwd line: tda:unused_by_nt/2000/xp:1000:513:U-laptop1\tda,S-1-5-21-2414507100-3802266639-3593817948-1000:/home/tda:/bin/bash The interesting thing is that if I open up a second command prompt and run an arbitrary cygwin command (like "less filename"). ssh successfully finds /home/tda/.ssh (but only for so long as that second command is running). I suspect this is something to do with the changes to mounts, but so far I've been unable to find a fix. I think we need more information about what you're actually doing and what your configuration is. Please review the problem reporting guidelines found here: Problem reports: http://cygwin.com/problems.html -- Larry _ A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email? -- 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
strptime doesn't fill in tm_wday and tm_yday.
Hello!
The following STC hints at a problem in strptime:
---8<
#include
#include
int
main(void)
{
/* seed tm with some garbage */
struct tm tm = {
0, 0, 0, /* s m h */
0, 0, 0, /* d m y */
290774, 2280577, 81
};
const char date[] = "2011-05-11 14:06:11";
if (!strptime(date, "%Y - %m - %d %T", &tm)) {
fprintf(stderr, "strptime error\n");
return 1;
}
printf("%s", asctime(&tm));
printf("tm_yday %d\n", tm.tm_yday);
printf("tm_wday %d\n", tm.tm_wday);
printf("tm_isdst %d\n", tm.tm_isdst);
return 0;
}
---8<
I get this output with Cygwin 1.7.9-1:
May 11 14:06:11 2011
tm_yday 2280577
tm_wday 290774
tm_isdst 81
I expect:
Wed May 11 14:06:11 2011
tm_yday 130
tm_wday 3
tm_isdst whatever
I get the expected output on the Linux host I tried (with tm_isdst=81),
but not on Solaris 10.
On Solaris 10 I get (for completeness):
Sun May 11 14:06:11 2011
tm_yday 0
tm_wday 0
tm_isdst 0
Opengroup has this to say about only filling in some fields:
"It is unspecified whether multiple calls to strptime()
using the same tm structure will update the current
contents of the structure or overwrite all contents of
the structure. Conforming applications should make a
single call to strptime() with a format and all data
needed to completely specify the date and time being
converted."
but I don't think it applies since indeed I do completely specify
the date in my strptime call.
In my "real" program, the call to asctime with the crippled tm
causes a seg-fault instead of "just" missing weekday output, I guess
it depends...
Cheers,
Peter
--
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: Who's using "CYGWIN=tty" and why?
On 5/11/2011 2:34 AM, Corinna Vinschen wrote: Kind of weird. The difference is that in tty mode the stdio handles are pipes, while in the notty case the stdio handles are console handles. Usually native Windows applications shouldn't see a difference and even work *better* in notty mode. One problem I ran into was with *Windows mode* applications (ie. MS link.exe option /SUBSYSTEM:windows) trying to detect stdout redirection. I apologize that this takes a bit of explaining first as to why we run into a problem with Cygwin. For Windows-mode applications, _isatty(_fileno(stdout)) will always return false. Due to a bug (in Windows and/or the CRT), the FILE *stdout object will be initialized to a black hole. So if you want printf's to make its way into the redirected file, you have to manually connect the FILE *stdout object to the redirected file output handle. The usual method is to call GetStartupInfo(&info) and check if info.dwFlags has the STARTF_USESTDHANDLES flag set. If it is set, then assume that info.hStdOutput contains the redirected file output handle and attach it with something like: *stdout = _fdopen(_open_osfhandle(info.hStdOutput, _O_TEXT)); So this brings us to Cygwin. When we spawn such a Windows mode app from Cygwin, the method I describe above fails. The call to _open_osfhandle(info.hStdOutput, _O_TEXT) returns with an error value of -1. This is likely why jam reports "the handle is invalid". Personally, when I first ran into this problem, I never realized that CYGWIN=tty would fix it. I did notice that there was a change in the behavior between Cygwin B20 and the Cygwin 1.X releases but I only realize now that this was probably the reason. Regards, -Edward -- 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
Problem with rebaseall 3.0.1-1
When doing rebaseall on a win 7 64 bit I got the following error: FixImage (/usr/x86_64-w64-mingw32/sys-root/mingw/bin/libgcc_s_sjlj-1.dll) failed with last error = 13 This blog http://ajaywhiz.posterous.com/installing-nodejs-on-windows-7 reports the same error and suggests the following solution: Add -e '/\/sys-root\/mingw\/bin/d' at line# 110 in /bin/rebaseall file. For me this did the trick and rebaseall could finish its job. I think this should be integrated into the stable code. Thanks. -- 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: Who's using "CYGWIN=tty" and why?
On Wed, May 11, 2011 at 11:02:40AM -0400, Edward Lam wrote: >On 5/11/2011 2:34 AM, Corinna Vinschen wrote: >> Kind of weird. The difference is that in tty mode the stdio handles are >> pipes, while in the notty case the stdio handles are console handles. >> Usually native Windows applications shouldn't see a difference and even >> work *better* in notty mode. > >One problem I ran into was with *Windows mode* applications (ie. MS >link.exe option /SUBSYSTEM:windows) trying to detect stdout redirection. >I apologize that this takes a bit of explaining first as to why we run >into a problem with Cygwin. > >For Windows-mode applications, _isatty(_fileno(stdout)) will always >return false. Due to a bug (in Windows and/or the CRT), the FILE *stdout >object will be initialized to a black hole. So if you want printf's to >make its way into the redirected file, you have to manually connect the >FILE *stdout object to the redirected file output handle. > >The usual method is to call GetStartupInfo(&info) and check if >info.dwFlags has the STARTF_USESTDHANDLES flag set. If it is set, then >assume that info.hStdOutput contains the redirected file output handle >and attach it with something like: >*stdout = _fdopen(_open_osfhandle(info.hStdOutput, _O_TEXT)); > >So this brings us to Cygwin. When we spawn such a Windows mode app from >Cygwin, the method I describe above fails. The call to >_open_osfhandle(info.hStdOutput, _O_TEXT) returns with an error value of >-1. This is likely why jam reports "the handle is invalid". > >Personally, when I first ran into this problem, I never realized that >CYGWIN=tty would fix it. I did notice that there was a change in the >behavior between Cygwin B20 and the Cygwin 1.X releases but I only >realize now that this was probably the reason. Just to go on mean record: I don't think the fact that jam works better as side effect of setting CYGWIN=tty is a good enough reason to derail any plans to get rid of CYGWIN=tty. It seems like you might be able to get the same behavior by saying jam &1 | cat cgf -- 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: Who's using "CYGWIN=tty" and why?
On 11 May 2011 16:02, Edward Lam wrote: > On 5/11/2011 2:34 AM, Corinna Vinschen wrote: >> >> Kind of weird. The difference is that in tty mode the stdio handles are >> pipes, while in the notty case the stdio handles are console handles. >> Usually native Windows applications shouldn't see a difference and even >> work *better* in notty mode. > > One problem I ran into was with *Windows mode* applications (ie. MS link.exe > option /SUBSYSTEM:windows) trying to detect stdout redirection. I apologize > that this takes a bit of explaining first as to why we run into a problem > with Cygwin. > > For Windows-mode applications, _isatty(_fileno(stdout)) will always return > false. Due to a bug (in Windows and/or the CRT), the FILE *stdout object > will be initialized to a black hole. That's not a bug, at least not in either Windows or Cygwin. Linking with /SUBSYSTEM:windows tells Windows that the program doesn't need a console, so Windows does neither attach it to the console of its parent process nor create a new console for it. This mean that there's nowhere for the standard handles to point to. (With CYGWIN=tty, the standard handles are connected to the pipes underlying Cygwin's pty implementation, which aren't affected by the /SUBSYSTEM:windows flag.) Andy -- 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: Who's using "CYGWIN=tty" and why?
On 5/11/2011 11:02 AM, Edward Lam wrote: So this brings us to Cygwin. When we spawn such a Windows mode app from Cygwin, the method I describe above fails. The call to _open_osfhandle(info.hStdOutput, _O_TEXT) returns with an error value of -1. This is likely why jam reports "the handle is invalid". PS. It would be interesting to find out why this fails. I would have expected that Cygwin/bash would have spawned the child process such that the inherited hStdOutput handle was open-able with _open_osfhandle(). -Edward -- 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: strptime doesn't fill in tm_wday and tm_yday.
On May 11 16:52, Peter Rosin wrote:
> Hello!
>
> The following STC hints at a problem in strptime:
>
> ---8<
> #include
> #include
>
> int
> main(void)
> {
> /* seed tm with some garbage */
> struct tm tm = {
> 0, 0, 0, /* s m h */
> 0, 0, 0, /* d m y */
> 290774, 2280577, 81
> };
> const char date[] = "2011-05-11 14:06:11";
>
> if (!strptime(date, "%Y - %m - %d %T", &tm)) {
> fprintf(stderr, "strptime error\n");
> return 1;
> }
>
> printf("%s", asctime(&tm));
> printf("tm_yday %d\n", tm.tm_yday);
> printf("tm_wday %d\n", tm.tm_wday);
> printf("tm_isdst %d\n", tm.tm_isdst);
> return 0;
> }
> ---8<
>
> I get this output with Cygwin 1.7.9-1:
> May 11 14:06:11 2011
> tm_yday 2280577
> tm_wday 290774
> tm_isdst 81
>
> I expect:
> Wed May 11 14:06:11 2011
> tm_yday 130
> tm_wday 3
> tm_isdst whatever
>
> I get the expected output on the Linux host I tried (with tm_isdst=81),
> but not on Solaris 10.
>
> On Solaris 10 I get (for completeness):
> Sun May 11 14:06:11 2011
> tm_yday 0
> tm_wday 0
> tm_isdst 0
>
> Opengroup has this to say about only filling in some fields:
>
> "It is unspecified whether multiple calls to strptime()
> using the same tm structure will update the current
> contents of the structure or overwrite all contents of
> the structure. Conforming applications should make a
> single call to strptime() with a format and all data
> needed to completely specify the date and time being
> converted."
>
> but I don't think it applies since indeed I do completely specify
> the date in my strptime call.
The Cygwin implementation of strptime is taken from NetBSD and enhanced
only in terms of support for the E and O modifiers. The NetBSD and
OpenBSD versions also support a non-POSIX format specifier %u (day of
week, monday = 1). Other than that, the Cygwin strptime behaves exactly
as the BSD implementation. tm_wday is only set if you specify %a, %A or
%w. tm_yday is only set if you specify %j.
Despite the example in the strptime man page of POSIX.1-2008, POSIX does
not specify that strptime has to fill out tm fields which are not also
specified in the format string. You should better memset the tm
structure to 0 before calling strptime.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader 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: GNU screen on Cygwin: Cannot seem to reattach, no matter what I try
On Wed, May 11, 2011 at 02:34, Corinna Vinschen wrote: > And you know, what have the romans ever done for us? ... apart from better sanitation and medicine and education and irrigation and public health and roads and a freshwater system and baths and public order ... -- 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: GNU screen on Cygwin: Cannot seem to reattach, no matter what I try
On May 11 13:08, Edward McGuire wrote: > On Wed, May 11, 2011 at 02:34, Corinna Vinschen wrote: > > And you know, what have the romans ever done for us? > > ... apart from better sanitation and medicine and education and > irrigation and public health and roads and a freshwater system and > baths and public order ... Exactly. Apart from that, nothing. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader 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: GNU screen on Cygwin: Cannot seem to reattach, no matter what I try
On Wed, May 11, 2011 at 09:32:06PM +0200, Corinna Vinschen wrote: >On May 11 13:08, Edward McGuire wrote: >> On Wed, May 11, 2011 at 02:34, Corinna Vinschen wrote: >> > And you know, what have the romans ever done for us? >> >> ... apart from better sanitation and medicine and education and >> irrigation and public health and roads and a freshwater system and >> baths and public order ... > >Exactly. Apart from that, nothing. FWIW, some of them are also ok directors with allegedly regrettable personal tendencies. cgf -- 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: GNU screen on Cygwin: Cannot seem to reattach, no matter what I try
Hi Andrew and Corinna, Yep, something about FAT32 appears to be the problem. As Corinna correctly notes, permissions are faked on FAT32. Doesn't matter what chmod I run, it's all 644 or 755. Apparently, GNU screen does not like this, but apparently it also doesn't give any error message that that's the problem. Might be worth adding a few lines to the source to provide somewhat more diagnostic error messages re: when socket files cannot be found or opened?!? At any rate, it works great now -- thanks!!! I set SCREENDIR=/cygdrive/c/tmp (an NTFS volume). Bingo, I can reattach. From same tty or different tty, whether console or remote. It's just like the old SCO Xenix days with Wyse 60 terminals -- woo-hoo! :) Only I'd take SCO Xenix over cmd.exe any day. :) Perhaps one for the FAQs...? Thanks again, Doug P.S., BTW, gotta love the Romans: we're just like 'em! :) :) On Tue, May 10, 2011 at 03:07:03PM -0400, Andrew Schulman wrote: > > 1. Output of 'cygcheck -svr' appended to the end of this message. > > Thanks, looks okay. > > > 2. I have the problem whether I run GNU screen from a cmd.exe prompt or > > under rxvt. I tried Peter Li's suggestion of trying to run screen under > > mintty -- still no joy. It does not matter if I running GNU screen from > > the console or if I'm logged in remotely, or if I try to detach and > > re-attach from the same tty or different ones. All efforts yield the > > same result: GNU screen cannot find anything to which to re-attach, even > > a session that I detached on the same tty just seconds before. > > > > 3. chmod 666 on the socket file did not work (its permissions were > > already 644, owned my 'morse', as shown in my original session long). > > No, I suggested that you try 0600, on the theory that your 0640 permissions > might be too permissive, and screen would refuse to use the socket. > Unlikely, but worth a try. > > However, if your socket is on a FAT file system, I don't know if you can > set 0600 permissions. > > > HOWEVER, I am wondering: my Cygin /tmp *IS* on a FAT32 filesystem, *NOT* > > an NTFS filesystem. Would that matter? Are socket files properly > > handled by Cygwin on FAT32? (I've never used a socket-based Cygwin > > program on this host before, at least not to my knowledge.) > > Hm, that could explain it. I don't recall this coming up before. > > Looking at screen(1), it says that sockets can go in "any mode 0700 > directory", and that you can set that in $SCREENDIR. So, I suggest trying > the following in order: > > (1) Run > > chmod 0700 /tmp/uscreens/S-morse > chmod 0600 /tmp/uscreens/S-morse/* > > then try to reattach. > > (2) If you can't set the above permissions because /tmp is on a FAT file > system, then find an NTFS directory and run > > export SCREENDIR=/path/to/ntfs/directory > > then start a new screen session, and see if you can reattach to it. > -- 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
Copy to network UNC path from crontab works in non-production, not in production
cygwin 1.7.7-1 Windows 2008 64-bit I have a script that I am trying to run from cron that copies a local file on a Windows 2008 server to a UNC path on another Windows 2008 server. It works fine in a non-Production environment, but not in Production and I can't figure out why. Yes, I've dutifully searched the forum and looked at http://cygwin.com/faq/faq-nochunks.html#faq.using.shares http://cygwin.com/cygwin-ug-net/ntsec.html The answer is not popping out at me. What I'm doing is basically this: cp a.a server-name\\sharename What I get in Production is: cp: cannot create regular file `//server-name/sharename': File exists But the file does not exist. I'm using the same Windows account on both the source and target servers in both environments and they have the same password on both servers. I don't see any differences between the non-Production and Production environments. I considered installing Cygwin on the target server in Production (even though it's not needed), so I did a test in a non-Production environment and it didn't work, so I haven't pursued that path. -- View this message in context: http://old.nabble.com/Copy-to-network-UNC-path-from-crontab-works-in-non-production%2C-not-in-production-tp31599258p31599258.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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: ssh - Could not create directory 'c/.ssh'.
On 5/11/2011 5:04 PM, Tim Allen wrote: Hi Larry On 11/05/11 15:45, Larry Hall (Cygwin) wrote: On 5/11/2011 6:44 AM, Tim Allen wrote: Hi I have happily used Cygwin ssh from "DOS" command prompt for many years but on upgrading to V1.7 get this error message. Further info: OS: Vista /etc/passwd line: tda:unused_by_nt/2000/xp:1000:513:U-laptop1\tda,S-1-5-21-2414507100-3802266639-3593817948-1000:/home/tda:/bin/bash The interesting thing is that if I open up a second command prompt and run an arbitrary cygwin command (like "less filename"). ssh successfully finds /home/tda/.ssh (but only for so long as that second command is running). I suspect this is something to do with the changes to mounts, but so far I've been unable to find a fix. I think we need more information about what you're actually doing and what your configuration is. Please review the problem reporting guidelines found here: Problem reports: http://cygwin.com/problems.html OK. Steps to reproduce: 1. Open command prompt, type: c:\ ssh fleet Could not create directory 'c/.ssh'. The authenticity of host 'fleet (192.168.1.30)' can't be established. RSA key fingerprint is 17:33:a7:32:cd:e1:04:ed:d7:3b:dc:11:c6:da:3c:42. Are you sure you want to continue connecting (yes/no)? 2. Open second command prompt, type: c:\ less main.c 3. Leave less running, return to first prompt and repeat login attempt: c:\ ssh fleet Linux fleet 2.6.32-5-686 #1 SMP Tue Mar 8 21:36:00 UTC 2011 i686 (login OK) cygcheck.out is output of cygcheck -s -v -r with less NOT running. cygcheck1.out is output of cygcheck -s -v -r with less running. The difference below looks relevant: cygcheck.out: Output from c:\cygwin\bin\id.exe UID: 0(tda) GID: 0(root) 0(root) 545(Users) Indeed. Some thoughts: 1. Check that you're using Cygwin's ssh. 2. Try unsetting "HOME" before running ssh. 3. Try running from a DOS prompt that is run as administrator. 4. Try a different directory. -- Larry _ A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email? -- 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: Copy to network UNC path from crontab works in non-production, not in production
On 5/11/2011 8:50 PM, CygwinNoob wrote: cygwin 1.7.7-1 Windows 2008 64-bit I have a script that I am trying to run from cron that copies a local file on a Windows 2008 server to a UNC path on another Windows 2008 server. It works fine in a non-Production environment, but not in Production and I can't figure out why. Yes, I've dutifully searched the forum and looked at http://cygwin.com/faq/faq-nochunks.html#faq.using.shares http://cygwin.com/cygwin-ug-net/ntsec.html The answer is not popping out at me. What I'm doing is basically this: cp a.a server-name\\sharename What I get in Production is: cp: cannot create regular file `//server-name/sharename': File exists So what's the difference between your "Production" and "non-Production" environments? What exactly are you doing in both environments? FWIW, you're better off using forward-slashes for pathnames in Cygiwn (i.e. //server-name/sharename). -- Larry _ A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email? -- 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: Copy to network UNC path from crontab works in non-production, not in production
Thanks for responding so quickly! I will try using the forward slashes in Production. It may take a few days because I don't have direct access to the Production environment and I have to go through sort of remote hands. The source server queries Oracle databases through shell scripts running in a Cygwin bash shell and sends the output files to the target server which is running SQL Server. No problem doing that interactively in Production, but I can't do it from ssh or cron in Production and I can do it in the non-Production environment. I cannot see any differences between the two environments. Larry Hall (Cygwin) wrote: > > On 5/11/2011 8:50 PM, CygwinNoob wrote: >> >> cygwin 1.7.7-1 >> Windows 2008 64-bit >> >> I have a script that I am trying to run from cron that copies a local >> file >> on a Windows 2008 server to a UNC path on another Windows 2008 server. >> It >> works fine in a non-Production environment, but not in Production and I >> can't figure out why. Yes, I've dutifully searched the forum and looked >> at >> >> http://cygwin.com/faq/faq-nochunks.html#faq.using.shares >> http://cygwin.com/cygwin-ug-net/ntsec.html >> >> The answer is not popping out at me. What I'm doing is basically this: >> >> cp a.a server-name\\sharename >> >> What I get in Production is: >> >> cp: cannot create regular file `//server-name/sharename': File exists > > So what's the difference between your "Production" and "non-Production" > environments? What exactly are you doing in both environments? > > FWIW, you're better off using forward-slashes for pathnames in Cygiwn > (i.e. //server-name/sharename). > > -- > Larry > > _ > > A: Yes. > > Q: Are you sure? > >> A: Because it reverses the logical flow of conversation. > >>> Q: Why is top posting annoying in email? > > -- > 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 > > > -- View this message in context: http://old.nabble.com/Copy-to-network-UNC-path-from-crontab-works-in-non-production%2C-not-in-production-tp31599258p31599359.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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
why cygwin have access to all the users in Windows
Hi I am newbie to cygwin. I am surprised at how cygwin have access to those directories belonging to users with a password and private access, that normally cannot be accessed from the normal Windows environment. How this happens? -- View this message in context: http://old.nabble.com/why-cygwin-have-access-to-all-the-users-in-Windows-tp31599578p31599578.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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: Copy to network UNC path from crontab works in non-production, not in production
On 5/11/2011 9:20 PM, CygwinNoob wrote: Thanks for responding so quickly! I will try using the forward slashes in Production. It may take a few days because I don't have direct access to the Production environment and I have to go through sort of remote hands. The source server queries Oracle databases through shell scripts running in a Cygwin bash shell and sends the output files to the target server which is running SQL Server. No problem doing that interactively in Production, but I can't do it from ssh or cron in Production and I can do it in the non-Production environment. I cannot see any differences between the two environments. If you're saying that in the non-Production environment it works both interactively and from cron and ssh, then I can only assume that something in the FAQ and User's Guide is in play on that machine. In general, access to network resources is restricted for services, which is what crond and sshd are. You need to follow the advice in the FAQ and/or User's Guide (the ones you referenced in your first post) to enable access for crond and sshd. -- Larry _ A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email? -- 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: why cygwin have access to all the users in Windows
On May 11 19:20, solde9 wrote: > > Hi I am newbie to cygwin. I am surprised at how cygwin have access to those > directories belonging to users with a password and private access, that > normally cannot be accessed from the normal Windows environment. How this > happens? Every admin has these rights, but they are usually disabled in the user token. See http://msdn.microsoft.com/en-us/library/aa446619%28VS.85%29.aspx Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader 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
