This is the mail archive of the
cygwin
mailing list for the Cygwin project.
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