GNU bug report logs -
#22584
cp could be more precise than "Not a directory"
Previous Next
Reported by: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
Date: Sun, 7 Feb 2016 16:20:01 UTC
Severity: wishlist
Tags: wontfix
Done: Assaf Gordon <assafgordon <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
Message #35 received at control <at> debbugs.gnu.org (full text, mbox):
severity 22584 wishlist
tags 22584 wontfix
close 22584
stop
(triaging old bugs)
On Tue, Feb 09, 2016 at 08:29:12AM +0100, Bernhard Voelker wrote:
> On 02/08/2016 10:28 PM, 積丹尼 Dan Jacobson wrote:
> > Ah ha, they just should have returned what the system calls said in the
> > first place, and not tinker with the output!
> >
> > Them tinkering with the output only makes things worse.
>
> Actually this _is_ an improvement:
>
> After stat() has detected that the target does not exist, cp simply
> tries to open() it - and while it has a trailing slash, the kernel
> returns EISDIR:
>
> stat("/tmp/My_DocVments/", 0x7ffdd335eee0) = -1 ENOENT (No such file or directory)
> ...
> open("/tmp/My_DocVments/", O_WRONLY|O_CREAT|O_EXCL, 0644) = -1 EISDIR (Is a directory)
>
> Taking this over as-is, the error diagnostic would be quite confusing and
> plain wrong:
>
> cp: cannot create regular file ‘/tmp/My_DocVments/’: Is a directory
>
> Therefore, the current mapping to ENOTDIR - introduced in coreutils-v8.8 -
> is the best we can do:
>
> $ cp .profile /tmp/My_DocVments/
> cp: cannot create regular file ‘/tmp/My_DocVments/’: Not a directory
>
> Your suggestion to say "no such file or directory" (ENOENT) would be misleading,
> because the target is treated by the system as a directory due to the trailing
> slash.
>
With no further follow-ups to this thread, I'm closing this bug.
-assaf
This bug report was last modified 6 years and 215 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.