FilePath.opEquals considers trailing path separator as a difference (and this is not documented)

It is a difference - the trailing slash means it is a folder.

Okay, try this:

assert (new FilePath("foo/") == (new FilePath("foo/bar")).pop);

If the trailing slash means that it's a folder and the lack thereof means it's a file, then .pop should keep the trailing slash. Since it doesn't, then the lack of a trailing slash means that the path could indicate a file or a folder, so opEquals should ignore the trailing slash.

Also, the following works:

assert ((new FilePath("/home")).isFolder);

It's a folder, with no trailing slash!

Given that a large portion of FilePaths? will be generated from user input, and users won't always include a trailing slash for folders, either the trailing slash doesn't matter, or you've introduced an unstated requirement that programmers need to expend extra effort in sanitizing input.

After discussing this with kris and larsivi, they indicated that the trailing '/' is useful and that POSIX requires it. This leaves a bug with FilePath?.pop, but that does not belong in this ticket.

This requirement is not documented. It should be displayed prominently.

You are right, this does not appear to be a requirement for FilePath. isFolder checks the file system unless you have said it was a folder.

I think that at least the internal folder indicator should be set if there was a trailing slash.

The question of the opEquals result is a difficult one if we don't require the / for folders. In fact, I find that the method has difficult semantics overall - what if two FP's point to the same file, but one with a relative path, the other absolute? To me there are only two real options - actual equality (low level same file node equality - impractical), or string equality, which means that foo doesn't equal foo/

(In [5448]) fixes #1891 :: FilePath?.opEquals considers trailing path separator as a difference (and this is not documented)

thanks to dhasenan

(In [5449]) closes #1893 :: FilePath?.pop removes the trailing path separator also fixes #1891 :: FilePath?.opEquals considers trailing path separator as a difference (and this is not documented) also fixes #1894 :: FilePath?: convenience method to add trailing path separator where appropriate

thanks to dhasenan