Bug 45142 - Delete Action does not delete unix path with "\" in it
Summary: Delete Action does not delete unix path with "\" in it
Status: NEW
Alias: None
Product: Ant
Classification: Unclassified
Component: Core tasks (show other bugs)
Version: 1.7.0
Hardware: PC Linux
: P2 major (vote)
Target Milestone: ---
Assignee: Ant Notifications List
: 44347 (view as bug list)
Depends on:
Blocks: 45136
  Show dependency tree
Reported: 2008-06-05 10:15 UTC by Torsten Krah
Modified: 2019-03-08 21:26 UTC (History)
2 users (show)


Note You need to log in before you can comment on or make changes to this bug.
Description Torsten Krah 2008-06-05 10:15:22 UTC

My build.xml got something like this:

<delete dir="${java.io.tmpdir}/${user.name}/antmod/${notastupidwindowspath}"/>

That path looks like this after variable replacement:

[1] /tmp/FRIENDS/krah/antmod/home/krah/Development/src/testproject/util

But my username is "FRIENDS\krah" so it must look like this:

[2] /tmp/FRIENDS\krah/antmod/home/krah/Development/src/testproject/util

[2] is a valid unix path and if it could be created it should be possible to remove it.
The "\" must not be replaced to / on Unix, as its a valid char.
Comment 1 Torsten Krah 2008-06-05 11:18:52 UTC
A suggested fix, it seems ok for me, maybe i've missed something, is to check for '/' as separatorChar and if true, skip the "\" replacement, something like this:

if(File.separatorChar != '/') {
 path = path.replace('\\', File.separatorChar);

Applying this to resolveFile and normalize Methods of FileUtils.java did the trick.
Good or bad idea?
Comment 2 Peter Reilly 2008-06-05 12:59:06 UTC
The only problem with the patch is that it would not be backward compatible.
There are a lot of ant scripts that start on windows machines, with \ used
line <... dir="build\aba".. etch.
These currennty work on unix.

Comment 3 Torsten Krah 2008-06-05 14:12:11 UTC
Thats right.
Hm how to solve this? 
Apply the patch anyway in a "future" version - if thats a possible way for ant developers and drop backward compatibility - or ignore this bug and make the valid "\" char on unix systems unusable?
Is it possible to implement some "hinting" to ant, to not "replace" the "\", if e.g. "noescape="true"" is set for that task? This sounds to me like a possible solution, isn't it?
Comment 4 Steve Loughran 2008-06-10 06:57:14 UTC
This is going to be trouble. Actually, I'm surprised lots of unixy things don't break with a \ in the usernam; I know spaces cause grief.

1. We cant say '\ is legitimate on unix', because we want build files to be cross platform.

2. we cant add double \\ escaping, as it comes from the property ${user.name}, which is JVM-generated. 

3. any task attribute that takes a file reference is going to be trouble.

Comment 5 Torsten Krah 2008-06-10 07:29:43 UTC
From my view i did not find any app which make trouble with the "\".
Although its "winbindd" default separator i changed it to be a "+" sign which results i a working ant without any fix to FileUtils.

But the problem still remains, with "\" as default domain - user separator the username gets a "\" which breaks ant file actions if username if involved.
Any other proposals how this can be fixed (without changing the username to be without a "\")?
Comment 6 Stefan Bodewig 2008-08-18 08:16:38 UTC
*** Bug 44347 has been marked as a duplicate of this bug. ***