File::Copy needs fixing #11545

p5pRT · 2011-08-03T00:44:36Z

Migrated from rt.perl.org#96158 (status was 'rejected')

Searchable as RT96158$

p5pRT · 2011-08-03T00:44:37Z

From perl-diddler@Ishtar.sc.tlinx.org

It looks like File::Copy is in the std distrib, and I'm using 5.12.

In it's docs, it says the unix version is, basically, 'broken',
and doesn't copy attributes, permissions/ date/times, acls, -- nothin.
It provides, essentially, DOS-FAT32 style copying: preserving nothing.

Instead of calling whatever broken routine that does this 'syscopy'?
(couldn't find it in 'apropos' and it's not a system call...hmmm..)
maybe it should just call the local 'cp -a' command to do the copy,
as it will copy links, preserve hard links, and as much of the metadata
as it can, i.e. 'all', for

all: ⊇ ⟦mode, ownership timestamps, xattr, links, [security] context, all⟧

i.e. 'File::Copy' should do at least as well as the system's standard
copy routine...dunnow what 'syscopy is' that it is documented to use,
as 'syscopy' doesn't turn up any manpages on my system.

Does syscopy mean 'use the system's 'cp' program?

In which case, maybe it should use the "-a" flag"?

-linda

Perl Info


Flags:
    category=library
    severity=high
    module=File::Copy

This perlbug was built using Perl 5.12.3 - Fri May  6 13:31:41 UTC 2011
It is being executed now by  Perl 5.12.3 - Fri May  6 13:26:30 UTC 2011.

Site configuration information for perl 5.12.3:

Configured by abuild at Fri May  6 13:26:30 UTC 2011.

Summary of my perl5 (revision 5 version 12 subversion 3) configuration:
   
  Platform:
    osname=linux, osvers=2.6.36, archname=x86_64-linux-thread-multi
    uname='linux build33 2.6.36 #1 smp 2011-02-21 10:34:10 +0100 x86_64 x86_64 x86_64 gnulinux '
    config_args='-ds -e -Dprefix=/usr -Dvendorprefix=/usr -Dinstallusrbinperl -Dusethreads -Di_db -Di_dbm -Di_ndbm -Di_gdbm -Duseshrplib=true -Doptimize=-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -Wall -pipe -Accflags=-DPERL_USE_SAFE_PUTENV'
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=define, usemultiplicity=define
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=define, use64bitall=define, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV -DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -Wall -pipe',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV -DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector'
    ccversion='', gccversion='4.5.1 20101208 [gcc-4_5-branch revision 167585]', gccosandvers=''
    intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
    ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -L/usr/local/lib64 -fstack-protector'
    libpth=/lib64 /usr/lib64 /usr/local/lib64
    libs=-lm -ldl -lcrypt -lpthread
    perllibs=-lm -ldl -lcrypt -lpthread
    libc=/lib64/libc-2.11.3.so, so=so, useshrplib=true, libperl=libperl.so
    gnulibc_version='2.11.3'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/usr/lib/perl5/5.12.3/x86_64-linux-thread-multi/CORE'
    cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib64 -fstack-protector'

Locally applied patches:
    


@INC for perl 5.12.3:
    /usr/lib/perl5/site_perl/5.12.3/x86_64-linux-thread-multi
    /usr/lib/perl5/site_perl/5.12.3
    /usr/lib/perl5/vendor_perl/5.12.3/x86_64-linux-thread-multi
    /usr/lib/perl5/vendor_perl/5.12.3
    /usr/lib/perl5/5.12.3/x86_64-linux-thread-multi
    /usr/lib/perl5/5.12.3
    .


Environment for perl 5.12.3:
    HOME=/home/law
    LANG=en_US.UTF-8
    LANGUAGE (unset)
    LC_CTYPE=en_US.UTF-8
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=.:/sbin:/usr/local/sbin:/opt/lsb/bin:/home/law/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/games:/opt/kde3/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin:/usr/lib/qt3/bin:/usr/sbin
    PERL_BADLANG (unset)
    SHELL=/bin/bash

p5pRT · 2011-08-03T07:14:42Z

From @Abigail

On Tue, Aug 02, 2011 at 05:44:38PM -0700, perl-diddler@Ishtar.sc.tlinx.org wrote:

# New Ticket Created by perl-diddler@Ishtar.sc.tlinx.org
# Please include the string: [perl #96158]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=96158 >

This is a bug report for perl from perl-diddler,
generated with the help of perlbug 1.39 running under perl 5.12.3.

-----------------------------------------------------------------
[Please describe your issue here]

It looks like File::Copy is in the std distrib, and I'm using 5.12.

In it's docs, it says the unix version is, basically, 'broken',
and doesn't copy attributes, permissions/ date/times, acls, -- nothin.
It provides, essentially, DOS-FAT32 style copying: preserving nothing.

Instead of calling whatever broken routine that does this 'syscopy'?
(couldn't find it in 'apropos' and it's not a system call...hmmm..)
maybe it should just call the local 'cp -a' command to do the copy,
as it will copy links, preserve hard links, and as much of the metadata
as it can, i.e. 'all', for

all: ⊇ ⟦mode, ownership timestamps, xattr, links, [security] context, all⟧

i.e. 'File::Copy' should do at least as well as the system's standard
copy routine...dunnow what 'syscopy is' that it is documented to use,
as 'syscopy' doesn't turn up any manpages on my system.

Does syscopy mean 'use the system's 'cp' program?

In which case, maybe it should use the "-a" flag"?

In File::Copy 2.15 and later, there's a slight difference between 'copy',
and 'cp'. The latter will preserve the permission bits, as the system 'cp'
doest. It doesn't preserve timestamps (since a plain 'cp' doesn't do so
either).

Perl 5.14 comes with a File::Copy that has the above.

Abigail

p5pRT · 2011-08-03T07:14:42Z

The RT System itself - Status changed from 'new' to 'open'

p5pRT · 2011-08-04T05:08:59Z

From perl-diddler@tlinx.org

Abigail wrote:

In File::Copy 2.15 and later, there's a slight difference between 'copy',
and 'cp'. The latter will preserve the permission bits, as the system 'cp'
doest. It doesn't preserve timestamps (since a plain 'cp' doesn't do so
either).

But Why should unix get the worst support when Syscopy on VMS,
OS/2, Mac and Win32, all use routines that preserve all the file attributes.

Why would one choose to do less on unix when the system 'cp'
command has the ability to copy everything.

Not copying metadata isn't copying the file file.

Now if the routine was named File::CopyData, it might be
different, but now days, I'd expect a digital copy to be 'precise' and
complete.

Is there some reason why this shouldn't be the default?

p5pRT · 2011-10-29T08:03:06Z

From @cpansprout

On Wed Aug 03 22:08:59 2011, LAWalsh wrote:

Abigail wrote:

In File::Copy 2.15 and later, there's a slight difference between
'copy',
and 'cp'. The latter will preserve the permission bits, as the
system 'cp'
doest. It doesn't preserve timestamps (since a plain 'cp' doesn't do so
either).
---
But Why should unix get the worst support when Syscopy on VMS,
OS/2, Mac and Win32, all use routines that preserve all the file
attributes.
Why would one choose to do less on unix when the system 'cp'
command has the ability to copy everything.
Not copying metadata isn't copying the file file\.

Now if the routine was named File&#8203;::CopyData\, it might be
different, but now days, I'd expect a digital copy to be 'precise' and
complete.
Is there some reason why this shouldn't be the default?

Probably backward compatibility.

--

Father Chrysostomos

p5pRT · 2012-09-19T01:45:27Z

From @jkeenan

On Sat Oct 29 01:03:06 2011, sprout wrote:

On Wed Aug 03 22:08:59 2011, LAWalsh wrote:
Abigail wrote:

In File::Copy 2.15 and later, there's a slight difference between
'copy',
and 'cp'. The latter will preserve the permission bits, as the
system 'cp'
doest. It doesn't preserve timestamps (since a plain 'cp' doesn't
do so
either).
---
But Why should unix get the worst support when Syscopy on VMS,
OS/2, Mac and Win32, all use routines that preserve all the file
attributes.
Why would one choose to do less on unix when the system 'cp'
command has the ability to copy everything.
Not copying metadata isn't copying the file file\.

Now if the routine was named File&#8203;::CopyData\, it might be
different, but now days, I'd expect a digital copy to be 'precise' and
complete.
Is there some reason why this shouldn't be the default?
Probably backward compatibility.

Father C:

Are there any issues remaining to be resolved in this RT?

If not, I propose we close it.

Thank you very much.
Jim Keenan

p5pRT · 2012-09-19T03:08:03Z

From @cpansprout

On Tue Sep 18 18:45:27 2012, jkeenan wrote:

On Sat Oct 29 01:03:06 2011, sprout wrote:
On Wed Aug 03 22:08:59 2011, LAWalsh wrote:
Abigail wrote:

In File::Copy 2.15 and later, there's a slight difference between
'copy',
and 'cp'. The latter will preserve the permission bits, as the
system 'cp'
doest. It doesn't preserve timestamps (since a plain 'cp' doesn't
do so
either).
---
But Why should unix get the worst support when Syscopy on VMS,
OS/2, Mac and Win32, all use routines that preserve all the file
attributes.
Why would one choose to do less on unix when the system 'cp'
command has the ability to copy everything.
Not copying metadata isn't copying the file file\.

Now if the routine was named File&#8203;::CopyData\, it might be
different, but now days, I'd expect a digital copy to be 'precise' and
complete.
Is there some reason why this shouldn't be the default?
Probably backward compatibility.
Father C:

Are there any issues remaining to be resolved in this RT?

I am not sufficiently familiar with File::Copy to answer that question.
I was only responding to the question about changing default behaviour.

--

Father Chrysostomos

p5pRT · 2012-09-19T03:08:04Z

From [Unknown Contact. See original ticket]

On Tue Sep 18 18:45:27 2012, jkeenan wrote:

On Sat Oct 29 01:03:06 2011, sprout wrote:
On Wed Aug 03 22:08:59 2011, LAWalsh wrote:
Abigail wrote:

In File::Copy 2.15 and later, there's a slight difference between
'copy',
and 'cp'. The latter will preserve the permission bits, as the
system 'cp'
doest. It doesn't preserve timestamps (since a plain 'cp' doesn't
do so
either).
---
But Why should unix get the worst support when Syscopy on VMS,
OS/2, Mac and Win32, all use routines that preserve all the file
attributes.
Why would one choose to do less on unix when the system 'cp'
command has the ability to copy everything.
Not copying metadata isn't copying the file file\.

Now if the routine was named File&#8203;::CopyData\, it might be
different, but now days, I'd expect a digital copy to be 'precise' and
complete.
Is there some reason why this shouldn't be the default?
Probably backward compatibility.
Father C:

Are there any issues remaining to be resolved in this RT?

I am not sufficiently familiar with File::Copy to answer that question.
I was only responding to the question about changing default behaviour.

--

Father Chrysostomos

p5pRT · 2013-01-15T03:23:22Z

From @jkeenan

On Tue Sep 18 20:08:03 2012, sprout wrote:

On Tue Sep 18 18:45:27 2012, jkeenan wrote:
On Sat Oct 29 01:03:06 2011, sprout wrote:
On Wed Aug 03 22:08:59 2011, LAWalsh wrote:
Abigail wrote:

In File::Copy 2.15 and later, there's a slight difference between
'copy',
and 'cp'. The latter will preserve the permission bits, as the
system 'cp'
doest. It doesn't preserve timestamps (since a plain 'cp' doesn't
do so
either).
---
But Why should unix get the worst support when Syscopy on VMS,
OS/2, Mac and Win32, all use routines that preserve all the file
attributes.
Why would one choose to do less on unix when the system 'cp'
command has the ability to copy everything.
Not copying metadata isn't copying the file file\.

Now if the routine was named File&#8203;::CopyData\, it might be
different, but now days, I'd expect a digital copy to be
'precise' and
complete.
Is there some reason why this shouldn't be the default?
Probably backward compatibility.
Father C:

Are there any issues remaining to be resolved in this RT?
I am not sufficiently familiar with File::Copy to answer that question.
I was only responding to the question about changing default behaviour.

I have reviewed the issues discussed in this ticket as well as the
commits which effectuated the changes Abigail described. The ticket
does not provide actionable items with respect to File::Copy. Hence I
see no reason to keep it open and am closing it now.

Thank you very much.
Jim Keenan

p5pRT · 2013-01-15T03:23:23Z

@jkeenan - Status changed from 'open' to 'rejected'

snoopyjc · 2022-04-22T20:35:05Z

Came here looking for a viable replacement for "cp -p" that worked across platforms. Oh well!! :-(

p5pRT closed this as completed Jan 15, 2013

p5pRT added Severity High distro-Linux type-library labels Oct 19, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

File::Copy needs fixing #11545

File::Copy needs fixing #11545

p5pRT commented Aug 3, 2011

p5pRT commented Aug 3, 2011

p5pRT commented Aug 3, 2011

p5pRT commented Aug 3, 2011

p5pRT commented Aug 4, 2011

p5pRT commented Oct 29, 2011

p5pRT commented Sep 19, 2012

p5pRT commented Sep 19, 2012

p5pRT commented Sep 19, 2012

p5pRT commented Jan 15, 2013

p5pRT commented Jan 15, 2013

snoopyjc commented Apr 22, 2022

File::Copy needs fixing #11545

File::Copy needs fixing #11545

Comments

p5pRT commented Aug 3, 2011

p5pRT commented Aug 3, 2011

From perl-diddler@Ishtar.sc.tlinx.org

p5pRT commented Aug 3, 2011

From @Abigail

p5pRT commented Aug 3, 2011

p5pRT commented Aug 4, 2011

From perl-diddler@tlinx.org

p5pRT commented Oct 29, 2011

From @cpansprout

p5pRT commented Sep 19, 2012

From @jkeenan

p5pRT commented Sep 19, 2012

From @cpansprout

p5pRT commented Sep 19, 2012

From [Unknown Contact. See original ticket]

p5pRT commented Jan 15, 2013

From @jkeenan

p5pRT commented Jan 15, 2013

snoopyjc commented Apr 22, 2022