Re: Nasty permissions / pathing bug on 1.7
Steven Hartland wrote: Just to be 100% clear its not the fact that the script errors, its the fact that the permissions after the initial DOS pathed chmod doesn't actually set the permissions correctly and doesn't throw any error. Also, it's not just perl, you can reproduce it in a shell: $ ls -l /tmp/test.exe ls: cannot access /tmp/test.exe: No such file or directory $ touch /tmp/test.exe $ ls -l /tmp/test.exe -rw-r--r-- 1 DKAdmin None 0 2009-12-01 17:36 /tmp/test.exe $ cygpath -w /tmp/test.exe F:\cygwin-1.7\tmp\test.exe $ chmod 777 'F:/cygwin-1.7/tmp/test.exe' $ echo $? 0 $ ls -l /tmp/test.exe -rw-r--r-- 1 DKAdmin None 0 2009-12-01 17:36 /tmp/test.exe I found a clue, but I don't know what it means: $ ls -l 'F:/cygwin-1.7/tmp/test.exe' -rwxr-xr-x 1 DKAdmin None 0 2009-12-01 17:36 F:/cygwin-1.7/tmp/test.exe $ ls -l 'F:\cygwin-1.7\tmp\test.exe' -rwxr-xr-x 1 DKAdmin None 0 2009-12-01 17:36 F:\cygwin-1.7\tmp\test.exe $ And no, I don't know why I didn't get the warning. I have nothing in my $CYGWIN. cheers, DaveK -- 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: Nasty permissions / pathing bug on 1.7
On Dec 1 17:42, Dave Korn wrote: Steven Hartland wrote: Just to be 100% clear its not the fact that the script errors, its the fact that the permissions after the initial DOS pathed chmod doesn't actually set the permissions correctly and doesn't throw any error. Also, it's not just perl, you can reproduce it in a shell: $ ls -l /tmp/test.exe ls: cannot access /tmp/test.exe: No such file or directory $ touch /tmp/test.exe $ ls -l /tmp/test.exe -rw-r--r-- 1 DKAdmin None 0 2009-12-01 17:36 /tmp/test.exe $ cygpath -w /tmp/test.exe F:\cygwin-1.7\tmp\test.exe $ chmod 777 'F:/cygwin-1.7/tmp/test.exe' $ echo $? 0 That's by design. When you use Win32 paths, instead of POSIX paths, you will get Win32 default permission handling. Or, in other words, for all DOS paths the mount mode is noacl. 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: Nasty permissions / pathing bug on 1.7
Corinna Vinschen wrote: That's by design. When you use Win32 paths, instead of POSIX paths, you will get Win32 default permission handling. Or, in other words, for all DOS paths the mount mode is noacl. Cheers, I was just off looking that up. It's obviously what's happening for perl too. cheers, DaveK -- 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: Nasty permissions / pathing bug on 1.7
- Original Message - From: Corinna Vinschen That's by design. When you use Win32 paths, instead of POSIX paths, you will get Win32 default permission handling. Or, in other words, for all DOS paths the mount mode is noacl. Ok that begs the questions:- 1. What was the reasoning behind this change? 2. Surely when performing changes on permissions with a mount mode of noacl it should be a fatal error? #2 I think is imperative as to leave the user thinking all is well is going to lead to real confusion, just like it did here, especially as this worked just fine in 1.5. I know the warning is there but at no point does it mention the fact it totally breaks anything that tries to manipulate permissions. Regards Steve -- 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: Nasty permissions / pathing bug on 1.7
On Dec 1 18:03, Steven Hartland wrote: - Original Message - From: Corinna Vinschen That's by design. When you use Win32 paths, instead of POSIX paths, you will get Win32 default permission handling. Or, in other words, for all DOS paths the mount mode is noacl. Ok that begs the questions:- 1. What was the reasoning behind this change? Win32 path - No POSIX path - no POSIX permissions. There was a thread on this list about this very problem a couple of months ago. It was generally agreed that handling Win32 paths this way consistently is a good thing. 2. Surely when performing changes on permissions with a mount mode of noacl it should be a fatal error? No. noacl means that permissions are faked. #2 I think is imperative as to leave the user thinking all is well is going to lead to real confusion, just like it did here, especially as this worked just fine in 1.5. I know the warning is there but at no point does it mention the fact it totally breaks anything that tries to manipulate permissions. It's easy. If you want POSIX permssion handling, stick to the POSIX world. 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: Nasty permissions / pathing bug on 1.7
- Original Message - From: Corinna Vinschen Win32 path - No POSIX path - no POSIX permissions. So then why does it have any permissions support at all? By allowing permissions to be read and obeyed, but not written, your sending out very much mixed messaging which is confusing at best and dangerous to the user at worst. A simple example is that process creation using the Win32 perl module under cygwin taking win32 paths fails when the execute permission set on the target binary is not set. This is the case which highlighted the problem to us. There was a thread on this list about this very problem a couple of months ago. It was generally agreed that handling Win32 paths this way consistently is a good thing. I would like to challenge this, as its unituitve, undocumented ( as far as I can see ) and very confusing for the user see above and below. 2. Surely when performing changes on permissions with a mount mode of noacl it should be a fatal error? No. noacl means that permissions are faked. It's easy. If you want POSIX permssion handling, stick to the POSIX world. That's easy to say but surely the entire goal of cygwin is to ease the interaction of Windows and POSIX functionality is it not? While I appreciate change is often required to make progress, it seems quite clear that this change in behaviour in its current state is very much a disaster waiting to happen or some users. Why do I say that? Well first off from our experience this was an nightmare to track down, taking several days to identify the source of this quite random behaviour. Now if your think about the number of scripts, binaries etc which may also be broken by this change but not know about it; surely that's not something you want to inflict on the cygwin user base is it? To be clear, my objection to this is not that it's been changed, although IMO doing so to be consistent doesn't seem like a very compelling reason given other aspects don't abide by the same rules; its that the change silently breaks things! Surely no one thinks that's an expectable state of play do they? To conclude, we've already changed our code in this particular example to workaround this issue and we're aware of it for the future, but how many others are going to get burnt and waste significant amounts of time tracking down issues created by this change if it remains in its current state? Given this I would respectfully like to propose either:- 1. Warn but preferably error when performing set permission operations on noacl mount points. 2. Revert so that Win32 paths aren't mounted with noacl. #1 with an error would be my personal preference. It would have allowed us to identify and correct this issue in seconds instead of the days it actually took. Regards Steve -- 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: Nasty permissions / pathing bug on 1.7
On Dec 1 19:37, Steven Hartland wrote: - Original Message - From: Corinna Vinschen Win32 path - No POSIX path - no POSIX permissions. So then why does it have any permissions support at all? By allowing permissions to be read and obeyed, but not written, your sending out very much mixed messaging which is confusing at best and dangerous to the user at worst. You can set the DOS R/O flag using chmod in this case. All other permissions are no permissions at all (FAT) or default Windows permissions, inherited from the parent directories. And chmod is working this way for ages. Actually, way back in the mist of times, switching the DOS R/O flag was all the chmod function could do. A simple example is that process creation using the Win32 perl module under cygwin taking win32 paths fails when the execute permission set on the target binary is not set. This is the case which highlighted the problem to us. Windows default is to set the execute bit for all files. Your scenario is puzzeling. If you created the files using Cygwin functions/tools, then why does the binary not have execute permissions? Why didn't you call chmod using POSIX paths? If you created the binary using native Win32 functions/tools, then why is it not executable by default? And why do you call chmod then, rather than SetSecurityInfo? You're mixing two worlds and are surprised that it leads to unexpected results? And you never saw the MS-DOS style path detected message? There was a thread on this list about this very problem a couple of months ago. It was generally agreed that handling Win32 paths this way consistently is a good thing. I would like to challenge this, as its unituitve, undocumented ( as far as I can see ) and very confusing for the user see above and below. Windows paths are going along with Windows default behaviour quite naturally. Expecting POSIX behaviour when using Windows paths is somewhat strange and *that* is unintuitive. 2. Surely when performing changes on permissions with a mount mode of noacl it should be a fatal error? No. noacl means that permissions are faked. It's easy. If you want POSIX permssion handling, stick to the POSIX world. That's easy to say but surely the entire goal of cygwin is to ease the interaction of Windows and POSIX functionality is it not? Maybe not the way you expect it. Other users disagree since they expect that Win32 paths behave the Win32 way. They complain that Win32 paths mixed with POSIX permission handling leads to surprising results. To conclude, we've already changed our code in this particular example to workaround this issue and we're aware of it for the future, but how many others are going to get burnt and waste significant amounts of time tracking down issues created by this change if it remains in its current state? And how many people get burned vice versa? There is no right way, there's just a way of least surprise and, even given your example, I'm still convinced that the current behaviour is the behaviour of least surprise. 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
