ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey N. Solofnenko" <>
Subject Re: Unwanted behavior - fixcrlf changes files to un-executable
Date Mon, 14 Aug 2006 20:17:08 GMT
Usually when a file is overwritten, its permissions are not changed.
Executable permission can be lost when the file first deleted, then
created again.

Carlton, if you have a special file extension or folder, you can run
<chmod> task after newlines are fixed.

- Alexey.

Dominique Devienne wrote:
> I'm afraid there's no fix, as Java is not permission-aware. <fixcrlf>
> probably creates a new file when it does something, and there's no way
> in Java to preserve the permissions. You could 'fix' the permissions
> after the fact, using <chmod> which simply forks to the command line
> chmod executable, assuming you know beforehand which files need fixing
> potentially.
> JDK 6 or later may add support for permissions, by right now there are
> no good work-around that I know of. --DD
> On 8/14/06, Brown, Carlton <> wrote:
>> Recently I started observing some very undesirable behavior in my Ant
>> scripts.   Specifically, when <fixcrlf> does its fixing, it also changes
>> the file permissions to be non-executable.  Now, I recognize this might
>> be a very Clever Thing because binaries could be corruped by <fixcrlf>.
>> But with regard to shell scripts, this is undesired behavior.   How do I
>> override/work around this?
>> The reason I run <fixcrlf> on shell scripts is because sometimes
>> boneheads edit them in Windows and then check them.   I could run around
>> and tell everybody not to do that, but I choose to make my process
>> self-correcting.   Except it doesn't work because Ant is trying to give
>> me help that I don't need.    What can I do here?
>> *****
>> The information transmitted is intended only for the person or entity 
>> to which it is addressed and may contain confidential, proprietary, 
>> and/or privileged material. Any review, retransmission, dissemination 
>> or other use of, or taking of any action in reliance upon this 
>> information by persons or entities other than the intended recipient 
>> is prohibited. If you received this in error, please contact the 
>> sender and delete the material from all computers. 162
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Alexey N. Solofnenko <>
Pleasant Hill, CA (GMT-8 usually)

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message