Re: [PATCH] tests/cp/cp-reply: --reply only accepts valid arguments
Brock Noland [EMAIL PROTECTED] wrote: On Wed, Apr 30, 2008 at 10:10 PM, Bob Proulx [EMAIL PROTECTED] wrote: Hopefully this helps, Yes, thank you! I will get to work... Which is preferred, one large patch or many small patches - one for each `logical' change? Many small changes are often better than one large one, unless e.g., the many small ones are all very similar. A safe reply is use your judgement ;-) If they're too small, it should be easy to merge them into larger ones mostly mechanically. Going the other way tends to be more manual. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [bug #23023] cp -r use a lot of memory, feature or memory leak?
Matteo Boccafoli [EMAIL PROTECTED] wrote: URL: http://savannah.gnu.org/bugs/?23023 Summary: cp -r use a lot of memory, feature or memory leak? ... # 21000 dir in 1.tar.bz2 $ cd /dev/shm /dev/shm$ time tar -xjf 1.tar.bz2 real0m8.403s user0m3.188s sys 0m5.196s /dev/shm$ time ./busybox cp -r /dev/shm/1/ /dev/shm/b real0m54.421s user0m0.832s sys 0m51.751s # [time t_1,t_2 : t_1t_2 and cp.memory(t_1)==cp.memory(t_2)] /dev/shm$ time /bin/cp -r /dev/shm/1/ /dev/shm/c real0m55.696s user0m2.680s sys 0m50.447s #[time t_1,t_2 : t_1t_2 and cp.memory(t_1)cp.memory(t_2)] # using a lot of memory (max 54 MB of RAM) Is it a feature or memory leak? As far as I know, cp has no memory leaks. However, a peak memory usage of 54MB does sound high. How did you measure it? I know that busybox cp fails to preserve some hard-link relationships that GNU cp does preserve. That may explain some of the difference. Note however, that cp is far from optimal. There is work underway to rewrite is using fts.c, and that should reduce its memory consumption in addition to making it more robust. I tried to duplicate your situation as follows but ended up with a peak memory usage of just 3.3 MB. (BTW, how many *non-directories* are in your tarball? Count with this command: find 1 -type f|wc -l ) # Create a hierarchy of 21000 directories, each containing # three empty files named a, b, and c. $ ( rm -rf /tmp/1; mkdir /tmp/1 cd /tmp/1 seq 21000 \ |xargs mkdir seq 21000|xargs -i% echo %/a %/b %/c|xargs touch ) # run cp under valgrind's memory profiler $ rm -rf massif.* /tmp/2; valgrind --tool=massif ./cp -r /tmp/1 /tmp/2 # display the first few lines of results (full output is over 2200 lines) $ ms_print massif.out.* Command:./cp -r /tmp/1 /tmp/2 Massif arguments: (none) ms_print arguments: massif.out.30264 MB 3.273^ ,# | ,# | .,@@@# | .. ::# | .@:: ::# | .. : :@:: ::# | .: :: : :@:: ::#. | , :: :: : :@:: ::#: |...@:@ :: :: : :@:: ::#: |..: :::@:@ :: :: : :@:: ::#: | ..::: :::@:@ :: :: : :@:: ::#: | @ .@ : :::@:@ :: :: : :@:: ::#: | @:: :@ : :::@:@ :: :: : :@:: ::#: | , . : @:: :@ : :::@:@ :: :: : :@:: ::#: | @: :: : @:: :@ : :::@:@ :: :: : :@:: ::#: | . ,@@: :: : @:: :@ : :::@:@ :: :: : :@:: ::#: |,. : @@@: :: : @:: :@ : :::@:@ :: :: : :@:: ::#: |.. :@: : @@@: :: : @:: :@ : :::@:@ :: :: : :@:: ::#: | ,.@:: :@: : @@@: :: : @:: :@ : :::@:@ :: :: : :@:: ::#: | .,@ @:@:: :@: : @@@: :: : @:: :@ : :::@:@ :: :: : :@:: ::#: 0 +---Mi 0 155.8 Number of snapshots: 63 Detailed snapshots: [2, 3, 4, 6, 10, 14, 15, 16, 21, 25, 34, 36, 43, 48, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60 (peak)] ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[bug #23023] cp -r use a lot of memory, feature or memory leak?
Follow-up Comment #1, bug #23023 (project coreutils): As suggest from Jim Meyering, I attach valgrind output using $ ./valgrind --tool=massif /bin/cp -r /dev/shm/1/ /dev/shm/c $ cp --version cp (GNU coreutils) 5.97 (file #15577, file #15578, file #15579, file #15580) ___ Additional Item Attachment: File name: massif.out.15750.gzSize:26 KB File name: ms_print.txt.gzSize:46 KB File name: massif.4613.txtSize:2 KB File name: massif.4613.ps Size:53 KB ___ Reply to this item at: http://savannah.gnu.org/bugs/?23023 ___ Messaggio inviato con/da Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
OO 2.2 freezes repeatedly on Freespire 2.0.8
Attn: Bug-coreutils@gnu.org Repeatedly, OO 2.2 has froze while saving a document; often this happens just as I open and select a line or two for placing in another document or place it in an email for sending. Then, I have to spend hours and hours to resolve the glitch. Last night I said, before going to bed, this is the latest response in the terminal mv: cannot move `/root/.openoffice.org2' to a subdirectory of itself, `/root/.openoffice.org2_backup/.openoffice.org2' what causes this? Yes, why does OO 2.2 easily freeze while saving? Once it happens, one can click Launch Run Command [terminal] enter mv ~/.openoffice.org2 ~/.openoffice.org2_backup but even that cure begins to fail. So, what is the next step that one may take to get freed of this hinderance? The following insights sent me by DrHu on the Freespire forum, is beyond my brain power. Read from DrHu who says http://forum.freespire.org/showthread.php?p=105526#post105526 as follows: https://bugs.launchpad.net/ubuntu/+s...ils/+bug/71174 https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/71174 mv --help Quote: mv --help Usage: mv [OPTION]... [-T] SOURCE DEST or: mv [OPTION]... SOURCE... DIRECTORY or: mv [OPTION]... -t DIRECTORY SOURCE... Rename SOURCE to DEST, or move SOURCE(s) to DIRECTORY. Mandatory arguments to long options are mandatory for short options too. --backup[=CONTROL] make a backup of each existing destination file -b like --backup but does not accept an argument -f, --force do not prompt before overwriting -i, --interactive prompt before overwrite --strip-trailing-slashes remove any trailing slashes from each SOURCE argument -S, --suffix=SUFFIX override the usual backup suffix -t, --target-directory=DIRECTORY move all SOURCE arguments into DIRECTORY -T, --no-target-directory treat DEST as a normal file -u, --update move only when the SOURCE file is newer than the destination file or when the destination file is missing -v, --verbose explain what is being done --help display this help and exit --version output version information and exit The backup suffix is `~', unless set with --suffix or SIMPLE_BACKUP_SUFFIX. The version control method may be selected via the --backup option or through the VERSION_CONTROL environment variable. Here are the values: none, off never make backups (even if --backup is given) numbered, t make numbered backups existing, nil numbered if numbered backups exist, simple otherwise simple, never always make simple backups Report bugs to bug-coreutils@gnu.org. I believe this is an OO 2.2 bug that needs a general solution. Write me back if I can provide further clarification. The question surely is beyond my knowledge. Please help us. Thanks. Kenneth Koym ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
added note OO2.2 won't save
Attn: bug-coreutils@gnu.org Allow me to add that I found by doing a Control S over the document titles, I was able to receive a message saying Successfully recovered. Another note said, Click on `finish' to clear the documents. But, I cannot get to the button having Click to finish. Do you have any idea what more can be done? Nothing having to do with OO2.2 is actionable. However, I can use Kwriter and save a document/file to one of many folders. Thanks. Ken Koym ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: OO 2.2 freezes repeatedly on Freespire 2.0.8
On Thu, 1 May 2008, Kenneth Koym wrote: Attn: Bug-coreutils@gnu.org Repeatedly, OO 2.2 has froze while saving a document; often this happens just as I open and select a line or two for placing in another document or place it in an email for sending. Then, I have to spend hours and hours to resolve the glitch. Last night I said, before going to bed, this is the latest response in the terminal mv: cannot move `/root/.openoffice.org2' to a subdirectory of itself, `/root/.openoffice.org2_backup/.openoffice.org2' what causes this? What version of coreutils to you have installed? The bug here is the misleading error message from mv as /root/.openoffice.org2_backup/.openoffice.org2 is not a subdir of /root/.openoffice.org2 As the Ubuntu bug you referenced points out, previous versions of mv would sometimes mistakenly fail with cannot overwrite directory (see http://lists.gnu.org/archive/html/bug-coreutils/2006-05/msg00086.html). Unfortunately, this cannot overwrite error message is disguising the real reason the mv command may be failing. Nonetheless, I'm confident that, even with a newer version of coreutils, your problems with OpenOffice freezing won't be resolved. As Bob points out in another reply the best people to ask about OpenOffice issues are OpenOffice support folks: http://support.openoffice.org/ Cheers, Phil ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
