[Issue 3862] std.file.copy does not have the same behavior as cp

via Digitalmars-d-bugs digitalmars-d-bugs at puremagic.com
Tue Nov 3 13:30:15 PST 2015


https://issues.dlang.org/show_bug.cgi?id=3862

--- Comment #9 from Vladimir Panteleev <thecybershadow at gmail.com> ---
(In reply to Jonathan M Davis from comment #8)
> (In reply to Vladimir Panteleev from comment #6)
> > For example, copying a file into the subdirectory if the destination path is
> > a directory is something that would, IMO, violate the principle of least
> > surprise.
> 
> Seriously? The fact that it _doesn't_ violates the principle of least
> surprise IMHO. I would never have expected a copy function to require that
> the target be a file rather than a directory.

No, I'm sorry but this is just wrong.

1. If the copy() call succeeds, and excluding things like race conditions, I as
a programmer expect that the destination path now refers to the file I just
copied. If I hand that path to another part of the program that expects a file
there but in fact finds a directory, the program will probably crash in a weird
way.

2. How do you know the path to the actual *file* that was created? I mean, one
COULD assume that it will be buildPath(dirName(target), baseName(source)), but
that's a non-trivial thing that now has to be part of the definition of what
exactly the function does.

3. Putting the file inside the directory could put the resulting path over the
OS/filesystem's path length limitation, which up to that point the program
might have meticulously been trying to avoid. The circumstance that the target
path could be a directory would need to be something the programmers would need
to think of, which I think is an unreasonable burden in this situation.

4. Checking if the target is a file or directory inside the copy function
creates the possibility of a race condition. I think we need to keep those out
of Phobos code and leave the burden on the user.

Furthermore:

5. What is the use case for this behavior? Let's look at the possible
circumstances:

a) If the program knows that the destination will be a file, then failing if
the destination is a directory is the correct thing to do. We also save the
programmers from an explicit check and race condition by throwing an exception
ourselves.

b) If the program knows that the destination will be a directory, then
calculating the final path is a trivial operation. Furthermore, it prevents
careless programmers from assuming that the target WILL be a directory - should
the target be a file their program would then act unexpectedly.

c) Finally, the program might not know if the destination is a file or
directory. Seriously, I think this case is rare enough to warrant requiring an
explicit check from the programmer, especially considering the problems
detailed above.

6. Do you know any programming languages whose copy function from their
standard library behaves like cp in this regard?

--


More information about the Digitalmars-d-bugs mailing list