[Haskell-cafe] RE: ANN: System.FilePath 0.9

[Neil Mitchell]

Hi Brian,

> I kind of expect that a Haskell library for file paths will use the
>  type system to ensure some useful properties about the paths.
I am specificially concentrating on type FilePath = String, because
that is how it is defined by Haskell 98. And consequently that's how
it works with readFile/writeFile/appendFile etc.

Perhaps a far better solution to this would not be to hack these kind
of guarantees in at the filepath level, but have a restricted IO monad
that only lets you perform operations inside certain directories, or
only lets you read/write files. I know that both House and Halfs use
these techniques. Without too much effort Yhc (for example) could be
modified to perform restricted IO operations (only on certain
directories etc).

You seem to want to distinguish between relative, relative down only
and absolute paths. By putting this in the filepath, and having
different types for each, you pretty much guarantee that all standard
functions will operate on all 3 types of path, so you don't gain any
security that way, since mistakes will still slip through. How about
adding something like "restrictFilePaths :: FilePath -> IO ()" which
will restrict the area that can be played with to that beneath the
given FilePath?


> I want to make sure a filename is valid. For example, "prn" and "con"
>  are not valid path elements for normal files on Windows, certain
>  characters are not allowed in filenames (depending on platform), some
>  platforms may require paths to be escaped in different ways. I see
>  there is a "isValid" function and even a (magical) "makeValid"
>  function, but they do not report what was wrong with the filename in
>  the first place. Furthermore, it isn't clear from the documentation how
>  these functions determine whether a filename is valid.
I don't check for prn and con, and I'm not sure if I should do. prn
and con are files, they just happen to be special - you can still
write to con for example. Maybe an isSpecial is more appropriate. The
basic idea of the check is that it can't contain invalid character,
for example ? in Windows. The motivation behind this is that programs
such as Wget often dump their url to disk using the filename bit - and
on windows this never works for urls with a ? at the end.

What isValid does is replace these "bad" characters with underscores.
I guess its perfectly reasonable to get some information on why a
filepath is invalid, so I'll add that.

> In this library proposal, there are a bunch of "xxxDrive" functions
>  that many Unix-oriented programmers are sure to ignore because they are
>  no-ops on Unixy systems.
Yes, I hope almost everyone will ignore these functions. I can't think
of many good reasons for playing with the drive, but as a FilePath
library its absolutely critical that the underlying functions all know
intimately about drives and are safe with respect to them. Because of
that there have to be these drive functions in the library, so I might
as well export them. If someone uses them then good for them, but
otherwise people can safely ignore them.

Thanks

Neil