Feature request: affuse support for more than 999 segments

[jdossett]

I need to mount an image (non-aff) that has more than 999 segments. I read your response in #20 and I don't know if that is the issue. Say for example I try to mount a split image named like this:

image.0001 ... image.1024. When I try to mount this split image I get an error:

$ sudo affuse split-ntfs.0001 /tmp/test
Can't open image file: Invalid argument

If I try to mount a set of split files with more than 1000 segments that go img.001... img.2048, The resulting .raw image is corrupt and cannot actually be mounted in any useful way

I am trying to find where the segments are "reassembled in the code to see if there is a 3 digit length hard coded but cannot find it. Can you point me to the right place or possibly create a fix for issues like this?

Thanks!

[jdossett]

I have been looking into this more, it looks like the fix would have to be in vnode_split_raw.cpp. There is a hard coded limit to 3 character file extensions in that file.

[sshock]

I took a look at split_raw_increment_fname(), and sure enough it is designed with a hard-coded limit of 3 characters.

But if you look a little closer you may notice that after .999 it looks for .A00, and from there it counts up using numbers and letters like so:

.A00 .A01 ... .A09 .A0A ... .A0Z .A10 ... .AZZ .B00 ...

Or in other words, like the comment says: / First digit goes A-Z, second and third go 0-9A-Z /

If my calculations are correct, that means after the first 1000 segments (.000 to .999), it can have up to 26 36 36 more, for a grand total of 34,696 segments.

Can you rename your segments using this pattern and give it a try?

[jdossett]

Thanks so much for the quick response. I tried changing the names and that does appear to let it read > 999 files.

However after that I get an error:

affuse: split_raw_open_internal errno=24
Can't open image file: Too many open files

It looks like there is a hard cap for 1024 files somewhere in the code. I am currently trying to hunt it down.

[jdossett]

Actually it turns out there looks to be a bug around line 142 in vnode_split_raw.cpp. I think

    /* Increment */
    if(incval(ext[2],10)){
    if(incval(ext[1],36)){
        if(incval(ext[0],36)){
        return EINVAL;
        }
    }
    }

should be

    /* Increment */
    if(incval(ext[2],36)){
    if(incval(ext[1],36)){
        if(incval(ext[0],36)){
        return EINVAL;
        }
    }
    }

As currently written the incrementing would go A09 -> A10 instead of A09->A0A as it should from indications in the comment at line 131.

Fixing this doesn't change the limited number of files (which actually appears to be 1021).

[jdossett]

Sorry about that. So there is no internal limit on the number of open files. That was a ulimit issue on my system, and not related to the code.

The bug in my previous comment, around incrementing is still an issue though. With those things fixed now everything is working for me.

Do you want me to create a PR around the incrementing bug?

[sshock]

Yes, please do create a PR for that. I agree with your assessment.

[jdossett]

PR created, closing this issue. Thanks again.

[sshock]

(the PR that fixes this was #29)