Change the default to not follow symlinks?

[harendra-kumar]

The listing and copying functions in this package follow symlinks by default. The usual unix utils (ls, find, cp) convention is to not follow symlinks by default and use an explicit option (usually -L) to follow symlinks. It will be nice if we are consistent with this convention, though it will require API behavior change for already published APIs.

[mrkkrp]

The functions have directory semantics and I would like to avoid changing them because there are libraries that depend on existing API (and semantics) now.

[harendra-kumar]

Its perhaps not a good default because it does not preserve symlinks while copying or listing. Copying will turn symlinks into duplicated directories or files rather than copying them as symlinks. Similarly when listing we cannot distinguish whether what we are seeing is a symlink or real dir/file.

Yes, there may be pain in fixing if something depends on those semantics. But, it may be easier now that the package is not too old. It may be harder to change later and will remain so forever. Not sure though if that's a real problem. I guess first time users might assume it to be otherwise and face surprises. If we don't fix we should at least emphasize well in the documentation that these APIs FOLLOW symlinks.

[mrkkrp]

Closing this. Docs we provide are the same as directory has and it should be assumed that semantics of the functions are the same as in directory. I propose you open an issue against directory and when they update their docs, ping me and I'll pick up these changes.

[harendra-kumar]

If we don't fix we should at least emphasize well in the documentation that these APIs FOLLOW symlinks.

This will help the users to at least know the current semantics.

[mrkkrp]

Not against that, but it should be stated in directorys docs first (more people use direcotory with vanilla FilePaths anyway).

[harendra-kumar]

I tried to look at all the directory package APIs with the intention of raising an issue there related to this behavior. But I could not find a single one which goes through directories recursively and follows symlinks. The only recursive functions are for removal and they have explicit documentation that they do not follow symlinks.

It seems path-io has this inconsistent behavior only in the recursive listing, walking and copying APIs, these APIs are exclusive to path-io.

[mrkkrp]

Would you like to open a PR that would clarify this in the path-io documentation?

[harendra-kumar]

I would favor changing the default. Though we have taken care of the looping problem via walkDir, we still have the problem of duplication in copying APIs and inconsistency with the rm APIs. No-follow-symlink is a saner default and is followed by all unix/gnu utils. But then the question is do you want to provide APIs with a follow option, how?

[mrkkrp]

inconsistency with the rm APIs

Consistency with Unix commands is not the aim of the package. Consistency with directory is. We will mirror functions from directory including their semantics. If you want different semantics, raise an issue on directory's issue tracker, then when directory gets functions with the desired behavior, we can wrap them in path-io.

Better for wider Haskell community too (people who use directory but not path-io).

[harendra-kumar]

There seems to be a communication gap here.

Consistency with Unix commands is not the aim of the package.

I meant "inconsistency with the rm APIs" of this package itself, not with the unix commands. For example removeDirRecur documentation says "symbolic links are removed without affecting their targets". But copyDirRecur follows and copies the targets of the symbolic links.

If you want different semantics, raise an issue on directory's issue tracker, then when directory
gets functions with the desired behavior, we can wrap them in path-io.

I was talking about only those functions that do not exist in directory package but exist exclusively in path-io for example copyDirRecur. Which means the problem exists exclusively in path-io and there is absolutely nothing to be done in the directory package.

I am not at all advocating consistency with unix commands, however, I do argue that the choice of default taken by unix commands/gnu utils is a good one, and is time tested. Therefore, if you are free to choose a default without other constraints it is a good one. As a trivial example consider a copyDirRecur on a directory that has a symlink to /, it will end copying the whole file system, which is not desirable by default (IMO).

[mrkkrp]

OK, that clarificates the situation. Perhaps we could switch to the new default and release a new major version.

[mrkkrp]

I'm re-opening this. Feel free to open a PR changing the default behavior to not following symlinks.

I'm in the process of performing some maintenance for all my active OSS projects. For path-io it means that there will be a new release soon. If you are busy I could look into this issues myself, although it would be much appreciated if you could open a PR for this change.