Proposed change for Win9x file permissions...

Bill C Riemers
Mon May 26 15:38:00 GMT 2003

I'm not saying there won't be problems if someone using this patch does something like:
    umask 777

I'm just saying it is a recoverable mistake.  The umask local to the current process at it's children only.  Executables should
still execute, but scripts probably won't.  However, just changing the umask back to something more reasonable recovers the file
permissions.  So even the person who edits the change into their .profile or /etc/profile will be able to restore the previous

As I said, a better patch would be to modify the "mount" command to use a "umask" for each mounted file system.  But I wanted to
keep the change minimal, since I can not really test Win9x systems.


----- Original Message ----- 
From: "Corinna Vinschen" <>
To: <>
Sent: Monday, May 26, 2003 4:08 AM
Subject: Re: Proposed change for Win9x file permissions...

> On Sun, May 25, 2003 at 04:10:10PM -0400, Bill C. Riemers wrote:
> >
> > > I like the idea as well but wouldn't that eventually cause problems if
> > > the umask disables the user bits?  I'm a bit concerned about the new
> > > arriving questions on the cygwin ML due to applications checking these
> > > bits in combination with clueless users.  It would be better, IMHO, if
> > > the umask couldn't mask the user bits at all, just the group and other
> > > bits.
> >
> > I seriously doubt it would result in serious problem, since the patch only
> > changes the file permissions that are visible via a "stat()" command, not
> > the actual permissions that Windows will use.  Case and point:  /cygdrive/c
> > shows up with perms 000 under cygwin, but there are not any serious
> > consequences of that bug, other than user confusion.
> What I mean are applications calling stat and getting permissions back
> which they don't like.  E.g. a shell which checks the permissions and
> refuses to run a script because it's not executable.
> Corinna
> -- 
> Corinna Vinschen                  Please, send mails regarding Cygwin to
> Cygwin Developer                      
> Red Hat, Inc.

More information about the Cygwin-patches mailing list