All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Cordes <peter@cordes.ca>
To: util-linux@vger.kernel.org
Subject: Re: [PATCH] fallocate: create mode 0666, that's what umask is for
Date: Wed, 07 Jan 2015 18:46:26 -0400	[thread overview]
Message-ID: <20150107224626.GS29504@cordes.ca> (raw)
In-Reply-To: <20150107090354.GA15715@x2.net.home>

On Wed, Jan 07, 2015 at 10:03:54AM +0100, Karel Zak wrote:
> On Tue, Dec 30, 2014 at 01:02:17AM -0400, Peter Cordes wrote:
> > diff --git a/sys-utils/fallocate.c b/sys-utils/fallocate.c
> > index 0e06524b8c5837a63230dc047233c657c50c1d7c..9af3bb8ce1492defda57cc17764197790bb34c8e 100644
> > --- a/sys-utils/fallocate.c
> > +++ b/sys-utils/fallocate.c
> > @@ -365,7 +365,7 @@ int main(int argc, char **argv)
> >  
> >  	/* O_CREAT makes sense only for the default fallocate(2) behavior
> >  	 * when mode is no specified and new space is allocated */
> > -	fd = open(filename, O_RDWR | (!dig && !mode ? O_CREAT : 0), 0644);
> > +	fd = open(filename, O_RDWR | (!dig && !mode ? O_CREAT : 0), 0666);
> 
>  Applied, but I have replaced the number with 
> 
>     S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH | S_IWOTH
> 
>  macros to keep the code more readable.

 0666 is more readable, to me.  With the macros, I have to stop and
look to see what each one is, and figure out if any bits are left out.
If you were testing one bit in a given permission set, using a macro
would probably be more readable, but 0666 says "everything but execute"
in a lot less time than it takes to mentally OR 6 macros together.

 Maybe I'm weird for normally using numerical args to chmod, rather
than chmod +x, and most people don't chmod 755 often?

 Obviously it's your call in the end, as maintainer, and either way
doesn't make a big difference, since it compiles identically.

 Thanks for taking a look at my patches.  I haven't had any new ideas
for my fallocate --dig-holes patch.  My local copy does what I want it
to, and I haven't thought of anything else I really want.  All it
needs is probably just cleaning up what's printed at various -v
levels, and maybe a hole-size option.

-- 
#define X(x,y) x##y
Peter Cordes ;  e-mail: X(peter@cor , des.ca)

"The gods confound the man who first found out how to distinguish the hours!
 Confound him, too, who in this place set up a sundial, to cut and hack
 my day so wretchedly into small pieces!" -- Plautus, 200 BC

  reply	other threads:[~2015-01-07 22:46 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-30  5:02 [PATCH] fallocate: create mode 0666, that's what umask is for Peter Cordes
2015-01-07  9:03 ` Karel Zak
2015-01-07 22:46   ` Peter Cordes [this message]
2015-01-08  9:13     ` Karel Zak
2015-01-08 18:26       ` Peter Cordes

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=20150107224626.GS29504@cordes.ca \
    --to=peter@cordes.ca \
    --cc=util-linux@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.