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

[via Digitalmars-d-bugs]

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

--- Comment #12 from Vladimir Panteleev  ---
(In reply to Jonathan M Davis from comment #11)
> @Vladimir Well, clearly you and I have very different expectations when
> copying files.

You haven't addressed any of the arguments I brought up.

> So, if we're not going to fix std.file.copy to work like cp, and I
> want a usable copy function, I'm clearly going to have to find the time to
> write one myself and use that, and then I'll avoid std.file.copy like the
> plague.

In that case, I'll have to keep in mind to avoid any code you write like a
plague ;) Because as I explained, in most situations using such a function is
just wrong, and will result in buggy programs that crash in strange places if
something doesn't go according to its plan.

--

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

[via Digitalmars-d-bugs]

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

--- Comment #11 from Jonathan M Davis  ---
@Vladimir Well, clearly you and I have very different expectations when copying
files. What I expect and what is pretty much exactly what cp does. e.g. with
cp, I always use directory for the target and never provide a file name unless
I'm renaming the file. And I screw it up every time that I use std.file.copy.
I've just never gotten around to fixing it like I should have. So, if we're not
going to fix std.file.copy to work like cp, and I want a usable copy function,
I'm clearly going to have to find the time to write one myself and use that,
and then I'll avoid std.file.copy like the plague.

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

D is the only language that I use with any regularity that even declares a copy
function. So, my primary experience with copying files is cp, and cp's behavior
is what I expect. I find std.file.copy's behavior to be very unfriendly in
comparison.

--

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

[via Digitalmars-d-bugs]

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

--- Comment #14 from Jonathan M Davis  ---
(In reply to Vladimir Panteleev from comment #12)
> (In reply to Jonathan M Davis from comment #11)
> > @Vladimir Well, clearly you and I have very different expectations when
> > copying files.
> 
> You haven't addressed any of the arguments I brought up.

I can see some corner cases where your concerns would be a problem, but in
general, cp does exactly what I want, and having to do a bunch of additional
checks is just annoying. And while I can definitely believe that there are
programs where race conditions would be a concern or where it could be
problematic to assume that the target is a directory, I've never personally
written or worked on a program where that was a concern.

(In reply to Vladimir Panteleev from comment #13)
> I just looked at Python, and it provides both variants. We could introduce
> "copyTo" which works in the same way, and perhaps also require that the path
> ends with a directory separator for the "copy inside directory" behavior to
> activate.

Requiring a terminating directory separator would be annoying, but having
separate functions where one requires that the target be a file and the other
is more liberal does make sense.

--

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

[via Digitalmars-d-bugs]

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

--- Comment #13 from Vladimir Panteleev  ---
(In reply to Vladimir Panteleev from comment #12)
> In that case, I'll have to keep in mind to avoid any code you write like a
> plague ;)

OK, sorry, that was over the top.

(In reply to Jonathan M Davis from comment #11)
> D is the only language that I use with any regularity that even declares a
> copy function. So, my primary experience with copying files is cp, and cp's
> behavior is what I expect. I find std.file.copy's behavior to be very
> unfriendly in comparison.

I just looked at Python, and it provides both variants. We could introduce
"copyTo" which works in the same way, and perhaps also require that the path
ends with a directory separator for the "copy inside directory" behavior to
activate.

--

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

[via Digitalmars-d-bugs]

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

--- Comment #8 from Jonathan M Davis  ---
(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.

> At this point, it might be too late to change the behavior of std.file.copy 
> at all.

With regards to copying into a sub-directory, it's definitely not too late,
because it's not a breaking change, but it's true that any changes made would
have to be done with care - though I obviously should have gotten to this ages
ago. I keep forgetting about this issue until I have to use std.copy and run
into problems using it.

--

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

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
 CC||thecybersha...@gmail.com

--- Comment #6 from Vladimir Panteleev  ---
We definitely DO NOT want to match the behavior of cp. cp is a tool primarily
aimed to be used directly by humans, hence some of its DWIM behavior and common
human mistake checks. std.file.copy is a function which will always be used as
part of a larger, more complicated program.

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. In most circumstances, the program will know if the destination path
should be a file or directory (assuming it exists), and the programmer can
write the intended behavior anyway. If the program expects that the destination
path doesn't exist or is a file, but is in fact a directory, then putting the
file inside the directory is definitely not something the programmer should
need to foresee and take into account for.

What we could draw comparisons with is how other programming languages'
standard libraries do it. At this point, it might be too late to change the
behavior of std.file.copy at all.

--

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

[via Digitalmars-d-bugs]

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

--- Comment #5 from Andrei Alexandrescu  ---
ping @Jonathan :o)

--

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

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #7 from Andrei Alexandrescu  ---
(In reply to Vladimir Panteleev from comment #6)
> We definitely DO NOT want to match the behavior of cp. cp is a tool
> primarily aimed to be used directly by humans, hence some of its DWIM
> behavior and common human mistake checks. std.file.copy is a function which
> will always be used as part of a larger, more complicated program.
> 
> 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. In most circumstances, the program will know if the destination
> path should be a file or directory (assuming it exists), and the programmer
> can write the intended behavior anyway. If the program expects that the
> destination path doesn't exist or is a file, but is in fact a directory,
> then putting the file inside the directory is definitely not something the
> programmer should need to foresee and take into account for.
> 
> What we could draw comparisons with is how other programming languages'
> standard libraries do it. At this point, it might be too late to change the
> behavior of std.file.copy at all.

That to me spells "let's close this". Obliged.

--

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

[via Digitalmars-d-bugs]

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

--- Comment #9 from Vladimir Panteleev  ---
(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?

--

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

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=15102

--- Comment #10 from Vladimir Panteleev  ---
BTW, see also issue 15102 for more discussion of "magic"/DWIM file/directory
behavior.

--

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

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu and...@erdani.com changed:

   What|Removed |Added

Version|2.040   |D2

--

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

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=3862



--- Comment #3 from Andrei Alexandrescu and...@erdani.com 2013-02-26 09:15:43 
PST ---
Jonathan, OK to assign this to you?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

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

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=3862



--- Comment #4 from Jonathan M Davis jmdavisp...@gmx.com 2013-02-26 10:12:59 
PST ---
 Jonathan, OK to assign this to you?

Fine with me. I'd forgotten about this, and it really should be taken care of.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

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

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=3862


David Simcha dsim...@yahoo.com changed:

   What|Removed |Added

 CC||dsim...@yahoo.com


--- Comment #1 from David Simcha dsim...@yahoo.com 2011-08-30 12:51:01 PDT ---
IMHO it's **much** more important for Phobos to be consistent across operating
systems than to be consistent with the native file copying command on each OS. 
Obviously they don't always conflict but where they do I think the former
should be favored.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

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

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=3862



--- Comment #2 from Andrei Alexandrescu and...@metalanguage.com 2011-08-30 
14:41:36 PDT ---
I think there's value in this insofar as we frame it as std.file.copy doesn't
obey the principle of least astonishment. Taking a peek at cp as an example is
fine as long as we're in the business of having a robust file copy routine and
not in the business of emulating everything cp does.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---