Are you sure that's where it's crashing? strrchr gets the last occurrence, so it seems to me that pt - 1 would be valid even if len is 0 and path is "..". Either way, we ought to implement formal bounds-checking if this is a problem in addition to any special handling. In particular, if ".." crashes it, "." or ".a" probably does too.

"." or ".a" probably does too.

Or "a.".

@Omnikron13 I think the easy fix here is to remove what you added and then below at the start of the else change

            pt = copy(pt + 1);
            int len = strlen(pt);

to something like

            int len = strlen(pt);
            if (len <= 1)
                return copy("application/octet-stream")
            else
                 len--
            pt = copy(pt + 1);

Are you sure that's where it's crashing? strrchr gets the last occurrence, so it seems to me that pt - 1 would be valid even if len is 0 and path is "..". Either way, we ought to implement formal bounds-checking if this is a problem in addition to any special handling. In particular, if ".." crashes it, "." or ".a" probably does too.

pt = strrchr(path, '.'); will index the last actual character before the null terminator, pt = copy(pt + 1); moves the pointer onto the null terminator, and finally pt[len - 1], which is equivalent to pt[0 - 1] will underflow.

Just . doesn't actually appear to occur; I guess it is filtered out somewhere else before getting here?

Files with single character extensions like .c or .h files are fine as strrchr() only causes a problem with .. because it takes the right-most character.

I believe that just this:

if(len < 1)
    return copy("inode/directory");

Should be sufficient to handle it that way. Is there a particular reason to return application/octet-stream over inode/directory?

The only concern I can think of is that this would misidentify any file that ends with just . as a directory, though I'm not sure how likely that eventuality is vs. it being .. that is detected.