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
View this message in rfc822 format
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 214 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.