call to writeable_directory in _unlink: Do we need it?

Larry Hall (RFK Partners, Inc)
Wed May 24 11:16:00 GMT 2000

At 12:54 PM 5/24/00, you wrote:
>"Larry Hall (RFK Partners, Inc)" wrote:
> > [...]
> > I guess I can only offer my opinion because I don't have any experience
> > with this code.  If writable_directory() is doing something wrong in both
> > the ntsec and nontsec modes, it should be fixed (where eliminating it is
> > 1 possible fix).  If its doing something wrong for just ntsec cases, I'd
> > say conditionalize it.  I guess the big question that your description
> > doesn't answer for me is, what do we loose by pulling it out as you
> > describe?
>What we loose is the following:
>In UNIX/Linux you may not
>         remove a file,
>         rename a file,
>         mkdir a new subdir
>if you don't have write permissions to the parent directory.
>In Windows you may all of the above. In Cygwin you are
>actually disallowed that for being similar to U*X.
>What we loose is that a user is disallowed to do something
>in Cygwin while s/he may do that when using cmd or Explorer
>under the same conditions.
>The difference between ntsec and nontsec is that ntsec acts
>(more or less) correct while nontsec only sets permission
>bits and UID/GID to common values which _never_ results in
>any problems with samba because the access function always
>is sure that the user has sufficient permissions.

I'm left with the impression that the best option is to use the 
writable_directory() call when ntsec is not enabled and skip it when
it is.  Sounds to me like it wreaks havoc on proper ntsec function
but gets as close to UNIX behavior as possible for nontsec.  If this
is indeed a valid synopsis of the pros/cons of this case, my high level
view of this conditionalize the use of writable_directory.  Did I miss
some important point?


More information about the Cygwin-developers mailing list