Re: [coreutils] RFC for adding file creation mode feature into touch utility.

[Rakib Mullick]

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