GNU bug report logs -
#21094
cp: add option to sort when copying
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 21094 in the body.
You can then email your comments to 21094 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-coreutils <at> gnu.org
:
bug#21094
; Package
coreutils
.
(Mon, 20 Jul 2015 00:18:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
"Steve Russell" <steve.russell2 <at> mail.com>
:
New bug report received and forwarded. Copy sent to
bug-coreutils <at> gnu.org
.
(Mon, 20 Jul 2015 00:18:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
When performing a recursive copy of a large number of files it would be helpful to have an option to copy the files in each directory in sorted order of the file names. There are a couple of use cases for this.
The first is to be able to easily observe the progress of the copy using the -v option. Currently, the "random" order of the copy means I can not tell how far the copy has progressed. On occasions I have seen cp -v display a top level directory starting with 'z' and assumed the copy was almost done only to see it start copying files from another directory earlier in the alphabet.
The second use case is sometimes I would like to start working with the destination files before the copy has completed. For example if I see the destination has the top level directory "foo", an ordered copy means I can work with directories that are alphabetically before "foo" knowing that they will not change.
Another minor use case is some mp3 players ignore the file names and metadata and always play tracks in the order they appear in the directory. Usually the filesystems used by these players will order directories in the same order files are added. For content like eBooks where track order is critical, a sorted copy would be a useful workaround for the limitations of these players.
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#21094
; Package
coreutils
.
(Mon, 20 Jul 2015 00:35:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 21094 <at> debbugs.gnu.org (full text, mbox):
On 19/07/15 07:09, Steve Russell wrote:
> When performing a recursive copy of a large number of files it would be helpful to have an option to copy the files in each directory in sorted order of the file names. There are a couple of use cases for this.
>
> The first is to be able to easily observe the progress of the copy using the -v option. Currently, the "random" order of the copy means I can not tell how far the copy has progressed. On occasions I have seen cp -v display a top level directory starting with 'z' and assumed the copy was almost done only to see it start copying files from another directory earlier in the alphabet.
>
> The second use case is sometimes I would like to start working with the destination files before the copy has completed. For example if I see the destination has the top level directory "foo", an ordered copy means I can work with directories that are alphabetically before "foo" knowing that they will not change.
>
> Another minor use case is some mp3 players ignore the file names and metadata and always play tracks in the order they appear in the directory. Usually the filesystems used by these players will order directories in the same order files are added. For content like eBooks where track order is critical, a sorted copy would be a useful workaround for the limitations of these players.
Thanks for the suggestion.
The implementation would be quite simple given that we already
sort directory entries by inode number to improve performance
(though note that that performance enhancement may not be
effective going forward with newer file systems and SSDs).
The implementation would leverage gnulib's SAVEDIR_SORT_NAME functionality.
The interface would probably mirror tar's --sort option.
I'm 55:45 for exposing this option to cp, install and maybe mv.
thanks,
Pádraig.
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#21094
; Package
coreutils
.
(Mon, 20 Jul 2015 13:48:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 21094 <at> debbugs.gnu.org (full text, mbox):
On 20/07/15 01:34, Pádraig Brady wrote:
> On 19/07/15 07:09, Steve Russell wrote:
>> When performing a recursive copy of a large number of files it would be helpful to have an option to copy the files in each directory in sorted order of the file names. There are a couple of use cases for this.
>>
>> The first is to be able to easily observe the progress of the copy using the -v option. Currently, the "random" order of the copy means I can not tell how far the copy has progressed. On occasions I have seen cp -v display a top level directory starting with 'z' and assumed the copy was almost done only to see it start copying files from another directory earlier in the alphabet.
>>
>> The second use case is sometimes I would like to start working with the destination files before the copy has completed. For example if I see the destination has the top level directory "foo", an ordered copy means I can work with directories that are alphabetically before "foo" knowing that they will not change.
>>
>> Another minor use case is some mp3 players ignore the file names and metadata and always play tracks in the order they appear in the directory. Usually the filesystems used by these players will order directories in the same order files are added. For content like eBooks where track order is critical, a sorted copy would be a useful workaround for the limitations of these players.
>
> Thanks for the suggestion.
>
> The implementation would be quite simple given that we already
> sort directory entries by inode number to improve performance
> (though note that that performance enhancement may not be
> effective going forward with newer file systems and SSDs).
>
> The implementation would leverage gnulib's SAVEDIR_SORT_NAME functionality.
>
> The interface would probably mirror tar's --sort option.
>
> I'm 55:45 for exposing this option to cp, install and maybe mv.
Upon consideration I'm down to 50:50.
For the progress use case, one can use rsync,
or perhaps an explicit progress option in cp.
For the mp3 order case, one can use tar --sort
to do the transfer.
thanks,
Pádraig.
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#21094
; Package
coreutils
.
(Mon, 20 Jul 2015 16:21:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 21094 <at> debbugs.gnu.org (full text, mbox):
Pádraig Brady <P <at> draigBrady.com> writes:
> For the progress use case, one can use rsync,
> or perhaps an explicit progress option in cp.
rsync also sorts.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#21094
; Package
coreutils
.
(Wed, 24 Oct 2018 20:51:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 21094 <at> debbugs.gnu.org (full text, mbox):
severity 21094 wishlist
tags 21094 wontfix
close 21094
stop
(triaging old bugs)
On 20/07/15 10:20 AM, Andreas Schwab wrote:
> Pádraig Brady <P <at> draigBrady.com> writes:
>
>> For the progress use case, one can use rsync,
>> or perhaps an explicit progress option in cp.
>
> rsync also sorts.
>
Given the above, and no further comments in 3 years,
I'm closing this bug.
-assaf
Severity set to 'wishlist' from 'normal'
Request was from
Assaf Gordon <assafgordon <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Wed, 24 Oct 2018 20:51:02 GMT)
Full text and
rfc822 format available.
Added tag(s) wontfix.
Request was from
Assaf Gordon <assafgordon <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Wed, 24 Oct 2018 20:51:02 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
21094 <at> debbugs.gnu.org and "Steve Russell" <steve.russell2 <at> mail.com>
Request was from
Assaf Gordon <assafgordon <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Wed, 24 Oct 2018 20:51:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Thu, 22 Nov 2018 12:24:10 GMT)
Full text and
rfc822 format available.
This bug report was last modified 6 years and 206 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.