Neil Mitchell wrote:
I have also added a canonicalPath function, support for spotting file\con as invalid and fixing it, support for \\?\ paths (if you don't know what they are, don't look it up, they are quite painful!) and a few very obscure corner cases which broke some of the properties.
I haven't been following this discussion very closely, but this caught my eye. Has anyone pointed out yet that eliminating ".." in a FilePath isn't valid in the presence of symbolic links? I vaguely recall that this is why Krasimir's System.FilePath library doesn't include normalisation. Normalisation that just changes separators, removes redundant separators and removes "." components is probably ok. I don't really see the point of fullPathWith. Isn't it just combine? I think shortPath is on dodgy ground, given the difficulty with normalising FilePaths, and the fact that paths are not unique in the presence of symlinks. The temporary file stuff is wrong - see System.IO.openTemporaryFile. The only way to reliably create a temporary file is to open it at the same time, otherwise there's a race condition. I have some other issues with naming, and the fact that the library mixes IO and non-IO functions. We should avoid referring to $PATH as the "path", since we already have FilePath. eg. spiltPath and getPath are talking about two very different things. Where you use the term Filename, I think it should probably be FilePath. I think we should consistently use a single term, preferably FilePath. Cheers, Simon