ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob Oxspring" <roxspr...@yahoo.com>
Subject RE: [SUBMIT] Attrib task (chmod for Windows)
Date Fri, 25 Jan 2002 23:51:59 GMT


> -----Original Message-----
> From: Jesse Stockall [mailto:jesse@cryptocard.com]
> Sent: Friday, January 25, 2002 10:58 PM
> To: Ant Developers List
> Subject: RE: [SUBMIT] Attrib task (chmod for Windows)
>
>
> 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'm thinking more of Java shops than platform specific shops.  If the build
is being run over a unix style filing system then the full chmod
capabilities are applicable and it seems crazy to deny these features. Sure
you have to have some chmod util installed in the path but if this sort of
thing is applicable to the filing systems you use then chmod will likely be
available - no matter the operating system.

Fair enough re the warnings - I just meant it should be logged somewhere so
that people can see what is (or isn't) going on.
>
> >
> > 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.

Surely since the system flag is meaningless on unix and likewise writable on
FAT these are not assured functionality either? I understand you want to
keep things simple but the particular argument seems to have holes :)

>
> 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).

Verifying the existence of chmod.exe in windows the windos path could be
done easily (once per ant session if performance is an issue) and verifying
NTFS is unecessary since cacls is present in the whole NT family.

I accept that the combined task may not be the way to go, but I'm sure that
in its place a group of simple clear tasks covering
chmod/chgrp/chown/cacls/attrib should find their way into the ant
distribution.  I'm more concerned that people looking at a build script
should be able to understand the permission settings whether they know the
semantics of a particular filing system's commands and parameters - all in
the elusive name of WORA.

Rob

>
>
>
> --
>  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>
>


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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


Mime
View raw message