A bug in cp
I recently found a bug in cp in FreeBSD-7.3 that was corrected in FreeBSD-9.
I checked DragonflyBSD's cp and the bug's still there.
It's easy to reproduce:
$ uname -a
DragonFly jb.umc8.ru 3.0-RELEASE DragonFly v18.104.22.168.ge2c75-RELEASE #0: Sat Apr 21 21:10:43 CEST 2012 firstname.lastname@example.org:/usr/obj/usr/src/sys/X86_64_GENERIC x86_64
$ rm -rf a b
$ mkdir a b
$ cp -rp a/ b/
cp: utimes: b/a: No such file or directory
cp: chown: b/a: No such file or directory
cp: chmod: b/a: No such file or directory
cp: chflags: b/a: No such file or directory
That's what how it works under FreeBSD-9:
This command actually doesn't do anything, but it causes a failure if the shell is executed with -e option.
#1 Updated by marino over 3 years ago
- Assignee set to dragonflybsd1
I have definitely run into this even on the master branch and I knew that DragonFly behavior was different that FreeBSD behavior.
What I don't know is why it's considered a bug.
Was there a PR written against FreeBSD that would outline posix standard, etc?
I will attempt to find proof that this is indeed buggy behavior, but if you have proof already it would be nice to post it here.
#2 Updated by marino over 3 years ago
- Status changed from New to Closed