mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Horms <horms@verge.net.au>
To: Roman Zippel <zippel@linux-m68k.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Siep Kroonenberg <siepo@cybercomm.nl>,
	278068@bugs.debian.org
Subject: Re: chmod messes up permissions on hfs filesystem
Date: Thu, 4 Nov 2004 13:35:46 +0900	[thread overview]
Message-ID: <20041104043543.GA9634@verge.net.au> (raw)
In-Reply-To: <20041104033129.GQ4511@verge.net.au>

On Thu, Nov 04, 2004 at 12:31:31PM +0900, Horms wrote:
> On Wed, Nov 03, 2004 at 05:00:35PM +0100, Roman Zippel wrote:
> > Hi,
> > 
> > On Tue, 2 Nov 2004, Horms wrote:
> > 
> > > Thanks for the patch, though the behaviour of the umask still seems
> > > rather odd. I would like to offer an updated patch which I believe
> > > makes the umask behave in the expected way. It also ensures
> > > that the write_lock bit is read from/written to disk correctly.
> > 
> > You apply the umask before updating the write bit, which is incorrect.
> 
> I tried to account for that, but perhaps I missed.

Hi,

I think that I am a little confused here.
By applying the umask after any write bits set from
disk or by the user they are overridden.
I thought the intention of the umask was to provide
a default, not to override user-derived values.

In the case of msdos, which I believe is where this came from
there are no user or disk inputs as the file system does
not have any permissions as such. So the umask can just be
unilaterally applied.

But in the case of hfs, where there is one permission bit,
I think it would make sense for user requests, which are subsequently
written to disk, to override the umask. Does that make sense?

-- 
Horms

      reply	other threads:[~2004-11-04  4:36 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-01  4:35 Horms
2004-11-01 11:05 ` Horms
2004-11-01 16:27 ` Roman Zippel
2004-11-02  3:56   ` Horms
2004-11-03 16:00     ` Roman Zippel
2004-11-04  3:31       ` Horms
2004-11-04  4:35         ` Horms [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20041104043543.GA9634@verge.net.au \
    --to=horms@verge.net.au \
    --cc=278068@bugs.debian.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=siepo@cybercomm.nl \
    --cc=zippel@linux-m68k.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®