Mail Archives: cygwin/2009/12/01/16:08:17
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
- Raw text -