Jesse Stockall wrote:
On Fri, 2002-01-25 at 14:09, Peter Janes wrote:

With two tasks, you have to duplicate every set of permissions in build.xml and know the syntax of the applicable commands on each platform, or risk breaking on platforms you haven't considered (for example, what happens when I compile your code on Mac?). Plus, remember that NT can have "extended" permissions similar to UNIX ACLs.

On OS9 neither task would run. On OSX chmod would run. & since chmod on the Mac accepts the same permission syntax as other Unixes there would be no problem. As for other platforms, nothing would happen, as both the chmod & attrib tasks perform a platform check.

The NT ACL's are more like chown/chgrp & chmod rather than just chmod.

But chmod is in there, which is what matters. :) A cross-platform chown/chgrp task raises other issues, like how to determine whether Ant is running as root.


There's another point I'd forgotten that leads to more problems--in Windows, as far as I know, only NTFS supports ACLs. If you're running a FAT-style filesystem, you don't have the option of setting permissions per-user, though I'm not sure how the acl commands behave when you try.

How would you determine whether to use chmod.exe or attrib.exe. Both can
be valid on Windows, but chmod can't handle all the attributes that
attrib can.

I'd say to use the tool that's native to the platform, because you'll know exactly where it is and what it can do. attrib for Win9x-style OSes, attrib and/or the acl tools for NT-style OSes, chmod for UNIX-style OSes, and whatever Mac has (perhaps a separate OS9 impl if necessary). You'd basically have a common interface and separate platform-specific implementations.


Optionally using chmod on Windows seems like more hassle than it's worth--I think it's more reasonable to expect a standard OS command to be present than an add-on. Of course, you're always going to have a user who wants to run chmod everywhere, but isn't that what <exec> is for?

Could be there's a reason Sun doesn't support file permissions in Java in the first place.... :)
--
fix, n., v. What one does when a problem has been reported too many
times to be ignored.
--The New Hacker's Dictionary, 3rd ed.



-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>



Reply via email to