Return-Path: 
 <ant-dev-return-23655-qmlist-jakarta-archive-ant-dev=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-ant-dev-archive@apache.org
Received: (qmail 61061 invoked from network); 25 Jan 2002 22:58:28 -0000
Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131)
  by daedalus.apache.org with SMTP; 25 Jan 2002 22:58:28 -0000
Received: (qmail 17500 invoked by uid 97); 25 Jan 2002 22:58:32 -0000
Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org
Received: (qmail 17347 invoked by uid 97); 25 Jan 2002 22:58:30 -0000
Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:ant-dev-unsubscribe@jakarta.apache.org>
List-Subscribe: <mailto:ant-dev-subscribe@jakarta.apache.org>
List-Help: <mailto:ant-dev-help@jakarta.apache.org>
List-Post: <mailto:ant-dev@jakarta.apache.org>
List-Id: "Ant Developers List" <ant-dev.jakarta.apache.org>
Reply-To: "Ant Developers List" <ant-dev@jakarta.apache.org>
Delivered-To: mailing list ant-dev@jakarta.apache.org
Received: (qmail 17335 invoked from network); 25 Jan 2002 22:58:30 -0000
Subject: RE: [SUBMIT] Attrib task (chmod for Windows)
From: Jesse Stockall <jesse@cryptocard.com>
To: Ant Developers List <ant-dev@jakarta.apache.org>
In-Reply-To: <FNEIJCINPBJBMKANOODNAEKADOAA.roxspring@yahoo.com>
References: <FNEIJCINPBJBMKANOODNAEKADOAA.roxspring@yahoo.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Evolution/1.0.1 
Date: 25 Jan 2002 17:58:14 -0500
Message-Id: <1011999494.25737.40.camel@homer>
Mime-Version: 1.0
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

On Fri, 2002-01-25 at 17:07, Rob Oxspring wrote:

> I agree - part of the problem is the semantics of the "perm" string this is
> specific to each command and IMHO would be far clearer to read as separate
> attributes readable, writable, executable in the case of chmod and
> readonly,hidden,system,archive for attrib - thus there would be no confusion
> of what the R means in each perm string.

Agreed


> 
> Determined to get some feedback (just tell me it sucks if you like) I'll
> restate my proposed combined task:
> 
> <filerights>
>   <fileset ... > ... </fileset>
>   <fat readonly="no" hidden="no"/>
>   <ntfs>
>    <grant user="RobertO"  access="full"/>
>    <grant user="Informatics"  access="read"/>
>    <grant user="everyone" access="read"/>
>   </ntfs>
>   <unix>
>     <user name="roberto"     readable="yes" writable="yes" executable="yes">
>     <group name="informatics" readable="yes" writable="no" executable="yes">
>     <all readable="yes" writable="no" executable="no">
>   </unix>
>   <fat readonly="yes" hidden="yes"/>
> </filerights>

I would rather have something like:

<permission readable="true" writable="false" system="true">
    <fileset ...>
    <unix who="uo"/>
</permission>

Which would do

Windows:
attrib +R +S <fileset>

Unix:
chmod uo+r <fileset>
chmod uo-w <fileset>

> 
> The full list of commands should be attempted on every platform and warning
> messages should be issued as commands fail (maybe calls to a given util
> should not be attempted once they have failed once).  I think the big
> selling point of a combined task is that people using it to set the unix
> permissions (for example) will be confronted by a bunch of ntfs permissions
> in the manual which should trigger the build engineer to think about NT
> permissions required and vice versa.  

Why would a Unix shop want to be "think" about NT permissions (or vise
versa)? The task should be smart enough not to attempt to set executable
on a Windows file. Unless -debug is enabled I don't want to see warnings
about things I know already (no system flag on Unix)

> 
> I think this approach would cover all bases, and gives the engineer enough
> control to specify the order in which the attribute setting gets attempted
> so that the desired affect is achieved.
> 
> Rob

IMO a permission task (attrib + chmod) should only support the level of
functionality that can be assured across target platforms. 

This means that chown/chgrp on Unix, NTFS acl's, chmod on Windows
(cygwin or path of NFS package) would be handled by other tasks, or by
exec. Most of these operations are dependent on things that may or not
be present (chmod.exe on Windows) or hard to verify (NTFS on Windows).


  
-- 
 Jesse Stockall			|	Tel: 1+ 613.599.2441 ext. 243
 CRYPTOCard Corporation		|	Fax: 1+ 613.599.2442	 	
 Suite 304, 300 March Rd.	|	email: jesse@cryptocard.com
 Ottawa, ON, Canada K2K 2E2	|	web: www.cryptocard.com 
---------------------------------------------------------------------


--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>