Mirrors down?
Ftp mirrors download some stuff then say: "550 Failed to change directory" http sites can't download setup.ini then stop. The cygwin installer usually works with no problem. What could I be doing wrong? -gene -- 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: cygwin permissions problem on a network drive
On 10/21/2011 10:39 AM, Corinna Vinschen wrote: On Oct 21 10:16, gds wrote: On 10/21/2011 06:55 AM, Corinna Vinschen wrote: On Oct 21 12:15, Lemke, Michael SZ/HZA-ZSW wrote: On Friday, October 21, 2011 10:50 AM Corinna Vinschen wrote: On Oct 20 18:58, gds wrote: On 10/18/2011 08:52 AM, Lemke, Michael SZ/HZA-ZSW wrote: I know this an old thread but I am in exactly the same situation as the OP. Access with 1.7.7 and before worked fine, 1.7.9 has this problem. The workaround with explicit noacl option works for me but it is rather awkward as I have to work with a lot of servers. So... ...has this happened now? In a snapshot? I couldn't find any further information. So from the reply below I take it hasn't been fixed/worked around in a snapshot. But my experiments show something has Wrong. It has been fixed in the snapshot. 1.7.9 tries to open the file with WRITE_DAC access which fails on some shares. The snapshots won't do that anymore. I explained what the problem is already. The buzzword is WRITE_DAC. Apparently you don't have permissions to change file permissions on that share. Cacls should show the exact layout of the file and directory DACLs. Does `chmod' work for you? It shouldn't either. In my case that it true, chmod fails. For me chmod *appears* to work (no errors on cmd line) but file permissions seen in "ls -l" don't change nor do they change in windows. This is *with* using the "noacl" mount option, isn't it? Without the "noacl" option you should get a "Permission denied" on chmod. Actually, I thought I was in normal mount mode with acl enabled but not sure. So tried experiment again... Right now, my mount shows this for o: drive: O: on /my-o-drive type ntfs (binary,noacl) I can cd to /my-o-drive/home/gds and do: rm testfile echo 1 > testfile cat testfile 1 rm -rf testdir mkdir testdir and all work. If I do chmod 000 testfile I see with ls -l: -r--r--r-- If I do chmod 777 testfile I see -rw-r--r-- So there is a small effect but not much. Now I change the mount so I see (the default): O: on /cygdrive/o type ntfs (binary,posix=0,user,nounmount,auto) and repeat the exercise (testfile and testdir previously deleted: cd /cygdrive/o/home/gds echo 1 > testfile bash: testfile: Permission denied mkdir testdir mkdir: cannot create directory `testdir': Permission denied This is with the current default cygwin1.dll, not a snapshot. So apparently, only with the noacl style mount can I create files or dirs via cygwin. And definitely if app using cygwin tries to change a permission, currently noacl is required. Apparently Michael Lemke is saying with a SS dll you can at least create files/dir via cygwin (that I may have also seen when I tried a SS dll, not sure). However, for me, I have to now use the the noacl mount method since my application (svn) needs to create files and dirs on the share and it also tries to set permissions. Sorry, in reading your previous explanations (quoted below), I am still not sure whether you are saying this new behavior is a feature or bug in cygwin, a bug in my app using cygwin (e.g., svn) something changed in windows setup of permissions. Just to put it here (since thread has become separated) here is what you said previously: I know what change in Cygwin is causing that problem, but unfortunately I could never reproduce the server share settings myself which result in the permission denied. If you want to discuss this with your admin, the problem is this: When Cygwin 1.7.9 tries to create a file on a filesystem which supports ACLs, it requests WRITE_DAC permissions in the open call. WRITE_DAC is the access right you need to create the permission bits in the file's ACL, what you see in Explorer under the Security tab. Now, in some environments, the settings of the shares are so, that this right is apparently not granted, even for the creator of the file. But, as far as earlier reports go, there seem to be no indication of this in the ACL. As I mentioned above, I experimented with this myself, but I have never managed to reproduce this setting on the server. So I neither know how this setting looks like, nor if there's a way to recognize such a share. So, for the time being, I will change this in Cygwin for the next version so that it doesn't request WRITE_DAC permissions when trying to create a file or directory on a network share. The result will be that every file creation on a network share with ACL support will try to open the file twice, the first time to create it, the second time to set the POSIX permissions. This slows down remote file creation again, but I don't see a useful way around it. Testing for an access denied error afterwards and trying again is rather awkward. Anyhow, with the workaround of using noacl mount, it is working OK for me. Let me know if there is anythi
Re: cygwin permissions problem on a network drive
On 10/21/2011 06:55 AM, Corinna Vinschen wrote: On Oct 21 12:15, Lemke, Michael SZ/HZA-ZSW wrote: On Friday, October 21, 2011 10:50 AM Corinna Vinschen wrote: On Oct 20 18:58, gds wrote: On 10/18/2011 08:52 AM, Lemke, Michael SZ/HZA-ZSW wrote: I know this an old thread but I am in exactly the same situation as the OP. Access with 1.7.7 and before worked fine, 1.7.9 has this problem. The workaround with explicit noacl option works for me but it is rather awkward as I have to work with a lot of servers. So... ...has this happened now? In a snapshot? I couldn't find any further information. So from the reply below I take it hasn't been fixed/worked around in a snapshot. But my experiments show something has Wrong. It has been fixed in the snapshot. 1.7.9 tries to open the file with WRITE_DAC access which fails on some shares. The snapshots won't do that anymore. I explained what the problem is already. The buzzword is WRITE_DAC. Apparently you don't have permissions to change file permissions on that share. Cacls should show the exact layout of the file and directory DACLs. Does `chmod' work for you? It shouldn't either. In my case that it true, chmod fails. For me chmod *appears* to work (no errors on cmd line) but file permissions seen in "ls -l" don't change nor do they change in windows. Also, in windows, I can't change any of my access rights; under file properties/security under "allow" all are checked except Full Control and Special permissions, none checked under "Deny" and all check marks are gray so I can't change them there either. Anyone can create, modify or delete any file, but no one can hide or write-protect any file (which would require changing permission/access rights). AFAIK, this is how it has always been on this share. If this assumption is correct, does that mean something changed in cygwin that is causing this possible bug? Good! That shows that my assumption is correct. You could talk to your admin first to find out if that is by design and maybe there could be something changed to allow changing permissions. This is by design here. IT wants it that way. I think ours is the same way but haven't asked. (Using cygwin for what I am doing "not approved" here :(). Then "noacl' is the only way for you. Yes, no snapshot cygwin1.dll helped. Went back to default. Now have only this in /etc/fstab: O: /my-o-drive dontcare binary,noacl 0 0 So now access drive with /my-o-drive instead of /cygdrive/o Otherwise, just mount the share with the noacl flag. Doing it. Again, I don't know why this happens. I can not reproduce this problem on my NTFS shares, other than by removing the WRITE_DAC permission from the affected files and directories. If there's any way to fix or workaround it in Cygwin, somebody who has that problem has to hunt it down. I am willing to try to hunt it down. What do you want me to check? Check with your admin and ask how they make sure that you can't set permissions. Did they just create a certain set of inheritable permissions or do they use some policy? That is what I'd like to know. The answer, however, will only help me to understand, it will not help you to avoid the "noacl" setting. Corinna -- 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: cygwin permissions problem on a network drive
On 10/18/2011 08:52 AM, Lemke, Michael SZ/HZA-ZSW wrote: I know this an old thread but I am in exactly the same situation as the OP. Access with 1.7.7 and before worked fine, 1.7.9 has this problem. The workaround with explicit noacl option works for me but it is rather awkward as I have to work with a lot of servers. So... ...has this happened now? In a snapshot? I couldn't find any further information. Thanks, Michael Same problem here. Someone said snapshots here, http://cygwin.com/snapshots/ , fixes the problem but I tried several cygwin1.dll from there and still have problems. Directory is created on network drive now but see message "can't set permissions ... on a file" when committing with svn. Strangely, if I commit from linux to the same mounted ntfs drive, it works. Haven't tried the noacl method. -gene -- 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: Windows ClearCase [Was: Cygwin Visuals]
Andrew DeFaria wrote: Gary Johnson wrote: Are you using ClearCase on Windows, or just ClearCase on Unix? We use both at work. I found that I couldn't execute "cleartool edcs" in rxvt because cleartool apparently requires a Windows Console. The editor (vim) ran fine, but the screen filled with a bunch of garbage when I closed vim. Are you able to run "cleartool edcs" in rxvt or ssh? One must remember when using rxvt that it uses ptys. Many Windows programs don't understand ptys. Cleartool is one of them. Try just typing in cleartool in an rxvt Window. You'll never see the prompt. Luckily I, and apparently you, rarely type in cleartool then enter in commands. You probably have your ct alias which is common. So then you do ct ls or ct lsview or ct checkout or ct co... etc. You then never hit the problem with ptys. ct edcs then introduces the problem because it effectively does: $ ct catcs > /tmp/$$ $ vim /tmp/$$ $ # check that file has changed and offer to setcs $ ct setcs /tmp/$$ So then you could do, roughly, the above (which is what I do) or perhaps script it. Sorry for the late reply but thanks for the information. Was wondering why the ct cmd prompts don't appear in rxvt until after I hit return, then it's too late (but defaults have been OK so far). Just thought I would add that I have no problem using gvim as editor when doing "ct edcs" command in cygwin. However, I realize this violates the purity of a console only implementation :). -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: svn / subversion does not print -- FIXED (I think)
Spiro Trikaliotis wrote: Hello, * On Mon, May 12, 2008 at 03:32:42PM -0400 gds wrote: No svn commands print, e.g., "svn help" comes up blank with no errors printed. I know this behaviour when I try to run the non-cygwin version of SVN (that is, "upstream version") inside of a bash. In most cases, the commands also block until I stop them with Ctrl+C. Just a wild guess: Could it be that you have a non-cygwin version in your path which gets in the way? Regards, Spiro. Only have the cygwin svn installed. This shows that the root cause is now fixed: http://www.nabble.com/FW%3A-svn---subversion-does-not-print-tt17197085.html -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: svn / subversion does not print
gds wrote: David Rothenberger wrote: On 5/12/2008 12:32 PM, gds wrote: No svn commands print, e.g., "svn help" comes up blank with no errors printed. This happened before and I wrote down in notebook "svn needs crypto pkg to run...". However, did not write down which "crypto" package. Installing the "crypt" cygwin package did not help. This only started after a cygwin upgrade and reboot. Before that it worked fine. Any ideas what I need to do? My WAG is that you're missing a DLL. Try running "cygcheck `which svn`" and look for messages about missing DLLs. If you find any, please report back to the list so the setup.hint can be fixed. Yes, strace and cygcheck both indicate that cygexpat-0.dll is missing and should be in /bin. Don't see it there. Just see an "expat" package in the installer, no libexpat0 as pointed out here: http://www.nabble.com/-PACKAGING-ERROR--subversion-1.4.5-2-td16959043.html Sounds like there is a packaging problem. Tried going back to svn 1.4.5-1 instead of latest 1.4.5-2 with same result. I was wrong, there is a libexpat0 (I was looking for "libxpat0"). Re-installing it seems to fix the problem. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: svn / subversion does not print
David Rothenberger wrote: On 5/12/2008 12:32 PM, gds wrote: No svn commands print, e.g., "svn help" comes up blank with no errors printed. This happened before and I wrote down in notebook "svn needs crypto pkg to run...". However, did not write down which "crypto" package. Installing the "crypt" cygwin package did not help. This only started after a cygwin upgrade and reboot. Before that it worked fine. Any ideas what I need to do? My WAG is that you're missing a DLL. Try running "cygcheck `which svn`" and look for messages about missing DLLs. If you find any, please report back to the list so the setup.hint can be fixed. Yes, strace and cygcheck both indicate that cygexpat-0.dll is missing and should be in /bin. Don't see it there. Just see an "expat" package in the installer, no libexpat0 as pointed out here: http://www.nabble.com/-PACKAGING-ERROR--subversion-1.4.5-2-td16959043.html Sounds like there is a packaging problem. Tried going back to svn 1.4.5-1 instead of latest 1.4.5-2 with same result. -gene -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
svn / subversion does not print
No svn commands print, e.g., "svn help" comes up blank with no errors printed. This happened before and I wrote down in notebook "svn needs crypto pkg to run...". However, did not write down which "crypto" package. Installing the "crypt" cygwin package did not help. This only started after a cygwin upgrade and reboot. Before that it worked fine. Any ideas what I need to do? Thanks, -gene -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
