Re: [coreutils] RFC for adding file creation mode feature into touch uti (original) (raw)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

From: Rakib Mullick
Subject: Re: [coreutils] RFC for adding file creation mode feature into touch utility.
Date: Sat, 8 Jan 2011 11:11:01 +0600

On Fri, Jan 7, 2011 at 11:06 PM, Jim Meyering <address@hidden> wrote:

Eric Blake wrote: > On 01/07/2011 09:23 AM, Pádraig Brady wrote: >>> Hmm - mkdir already supports -m/--mode, so it does sound like making >>> touch support the same option might be a useful enhancement.  Of course, >>> if the file exists, the --mode option would be ignored.  And POSIX >>> requires that if the --mode option is not provided but a file is >>> created, that the file have mode 0666 as modified by umask.  We can't >>> use -m, though (POSIX already requires it for mtime). >> >> Why does mkdir have this option rather than relying on umask? >> My guess is to close security races with sticky bits etc. >> and that creating a file will not have the same issues? > > mkdir has -m because POSIX requires it; also, you are right that the > setup of 'mkdir -p -m' creates a hierarchy where you want the > permissions to be set correctly for the entire set for race avoidance. > But touch does not create hierarchies. > >> >> ... >>> I'm 70:30 for adding this idea, and it's rather simple to do, as well >>> (would still need doc, NEWS, and test additions). >> >> I'm a little less enthused to diverge from POSIX for this. > > It's not diverging from POSIX, so much as adding an extension.  It all > boils down to whether the extension would prove useful, and whether it > can optimize work flows faster than any existing alternative that gets > the same end result but with more steps.  But thinking about it more, > I'd rather use just the long-option --mode rather than burn a short > option -M (or any other). > > As for creating a file with +x or with 07000 permissions already added, > why?  Creating an empty file as already executable or setuid doesn't > make much sense (the empty file will be a nop); why not wait until the > file has final executable contents before adding +x or special > permissions later?  So, that leaves only permissions matching of a > reference file (and recent GNU cp already supports that), or restricting > permissions less than touch's default of 0666 (but touch honors umask, > so just modify your umask before touch), neither of which need a chmod > after the fact, nor a --mode argument to touch. > > What would really clinch the deal is if any other touch implementation > out there already has something like this.  But off the top of my head, > I don't know of any (neither FreeBSD nor Solaris touch provides anything > like this).  So I guess I'm now 50:50 (undecided on whether the > extension makes sense without more evidence of its usefulness).

I confess that my first reaction was "why bother?" Touch is nominally a very simple tool, and adding --mode support feels like adding unwarranted bloat -- and not in line with the one-job-one-tool philosophy.

Yes, right. Then, touch only supposed to change file's timestamp. No? But, touch also creates a file for us. Not only it creates a file for us, when it creates a file it takes reference from other files. So, althrough we're in philosophy of one-tool-do-one-job-well, there are something else that we can get.

And if adding --mode option to touch gets really out of philosophy, then I think we need a new tool to for creating file with all the options that we might have want. That will truly help us to keep the philosophy intact.

Why would one prefer the GNU-specific touch --mode ... over the portable combination of touch and chmod?

Cause its easier to do 'touch --mode xxx filename' than 'touch filename' and 'chmod xxx'. And Eric also pointed out that we will be able to do 'touch -r a -M b' to create a referenced file with different mode.

thanks, rakib