issue with dirDetails() and space at folder name end

Question

Hi, i'm using version a old verison 1.4.2, and i have issue with return of dirDetails method, folder names with space at the end are returned incomplet,
space's are removed.

is it normal?
is there a fix in newest versions?

any idea? :idea: :?:

thank you.

Answer 1

We've never tested with this scenario. It isn't exactly common to finish directory names with a space. I can't imagine why anyone would do that.

Answer 2

It isn't exactly common to finish directory names with a space.

I agree with you, but unfortunatly there is a lot of software that do this sort of things, for exemple "Final Cut Pro" on Mac os X.

Even if it's not used it's possible to do that on most Unix, and Linux file system.

anyway I have to deal with it, is there a walkaround?

Answer 3

Do you mean *contains* a space or *ends with* a space. The former should work, the latter may not.

It isn't exactly common to finish directory names with a space.

I agree with you, but unfortunatly there is a lot of software that do this sort of things, for exemple "Final Cut Pro" on Mac os X.

Even if it's not used it's possible to do that on most Unix, and Linux file system.

anyway I have to deal with it, is there a walkaround?

Answer 4

I mean *ends with* one or more space ie:

-this folder name work /john Do/
-this folder name is listed /john Do / but his name is cut "john Do"

Answer 5

here is what i can debug with my eclipse, as you can see the "name" is different than the raw name, if i try with a "normal" folder name the raw array just end after the last char.


name ".toto0000"
count 9
hash 0
offset 50
value char[63] (id=2166)
[0] d
[1] r
[2] w
[3] x
[4] r
[5] -
[6] x
[7] r
[8] -
[9] x
[10]
[11] 1
[12]
[13] r
[14] o
[15] o
[16] t
[17]
[18] r
[19] o
[20] o
[21] t
[22]
[23]
[24]
[25]
[26]
[27]
[28]
[29]
[30]
[31]
[32]
[33]
[34]
[35] 0
[36]
[37] N
[38] o
[39] v
[40]
[41] 2
[42] 8
[43]
[44] 1
[45] 4
[46] :
[47] 1
[48] 4
[49]
[50] .
[51] t
[52] o
[53] t
[54] o
[55] 0
[56] 0
[57] 0
[58] 0
[59]
[60]
[61]
[62]

Answer 6

This happens because the string is trimmed.

You can easily fix it by modifying the parser. There's a line in UnixFileParser.java:

String remainder = raw.substring(pos).trim();

Just remove the trim() and recompile.

There's a similar bit of code in WindowsFileParser.java - I can't tell without seeing a listing which one you are using.

Answer 7

My debug lead me to the same conclusion than you I have remove the 2 .trim() the one for link and the one for file/folder name in UnixFileParser.java and now it's working perfectly on every unix server that i can connect to.

I think this is just a UNIX issue, in my opinion, the whole last parameter of a unix answer is part of the name.

Do you think you will fix it in the next release?

thank you.

Answer 8

Yes, I think it'll be ok for us to apply this fix. People can always trim the name themselves if it is a problem.

Answer 9

sorry it still an issue because of the remove of trim() the offset (ie. pos) must be incremented, otherwise there is a "space" that is not part of the name that is added at the begining of names.

// we've got to find the starting point of the name. We
// do this by finding the pos of all the date/time fields, then
// the name - to ensure we don't get tricked up by a userid the
// same as the filename,for example
int pos = 0;
boolean ok = true;
for (int i = dateTimePos; i < dateTimePos+3; i++) {
pos = raw.indexOf(fields[i], pos);
if (pos < 0) {
ok = false;
break;
}
else { // move on the length of the field
pos += (fields[i].length()+1);
}
}
if (ok) {
//String remainder = raw.substring(pos).trim();
String remainder = raw.substring(pos);
if (!isLink)
name = remainder;
else { // symlink, try to extract it
pos = remainder.indexOf(SYMLINK_ARROW);
if (pos <= 0) { // couldn't find symlink, give up & just assign as name
name = remainder;
}
else {
int len = SYMLINK_ARROW.length();
//name = remainder.substring(0, pos).trim();
name = remainder.substring(0, pos);
if (pos+len < remainder.length())
linkedname = remainder.substring(pos+len);
}
}
}

Answer 10

Yes. There is also the possibility that it is more than one space. Instead, use this trimStart() method which we'll add - replacing the trim(). Not actually run this code yet but should work I think.

  
    /**
     * Trim the start of the supplied string
     * 
     * @param str   string to trim
     * @return string trimmed of whitespace at the start
     */
    protected String trimStart(String str) {
        StringBuffer buf = new StringBuffer();
        boolean found = false;
        for (int i = 0; i < str.length(); i++) {
            char ch = str.charAt(i);
            if (!found & Character.isWhitespace(ch))
                continue;
            found = true;
            buf.append(ch);
        }
        return buf.toString();
    }