This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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

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.


-- Problem reports: FAQ: Documentation: Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]