[bug #23023] cp -r use a lot of memory, feature or memory leak?

[Jim Meyering]

Update of bug #23023 (project coreutils):

 Privacy: Private => Public 


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
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

[Philip Rowlands]

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

added note OO2.2 won't save

[Kenneth Koym]

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

[Bob Proulx]

Kenneth Koym wrote:
>   Repeatedly, OO 2.2 has froze while saving a document; often this 

Ah...  You have found the 'mv' people but not the 'openoffice'
people.  We don't know maintain openoffice here.

> mv: cannot move `/root/.openoffice.org2' to a subdirectory of itself, 
> `/root/.openoffice.org2_backup/.openoffice.org2'
> what causes this?"

That is an error _from_ mv about an incorrect use of it _by_ something
else.  That doesn't actually mean there is a bug in mv.  That is where
the confusion came into place.

> 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?"

This is an error in the sue of mv.  It is telling you exactly what it
says, that it cannot move a directory into a subdirectory of itself.
Try this smaller example.

  $ mkdir /tmp/dir1
  $ mkdir /tmp/dir1/subdir1
  $ mv /tmp/dir1 /tmp/dir1/subdir1/
  mv: cannot move `/tmp/dir1' to a subdirectory of itself, 
`/tmp/dir1/subdir1/dir1'

That should illustrate the problem better because it is smaller and
easier to understand.  You can't move a parent directory into the
child directory of itself.  It would break its own parent directory.
If /tmp/dir1 is moved then how would you reach /tmp/dir1/subdir1?  It
would then be lost and left floating in the filesystem with no way to
reach it.

> mv --help
> ...
> Report bugs to .

You have found the right folks to talk about 'mv'.  But I don't see
any problem in your report about the mv command.  It is reporing a
logically incorrect use of the program.

> 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.

You will need to take this problem up with the openoffice folks.

  http://support.openoffice.org/

Bob

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?"
> 
> 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 
> 
> 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 .
> 
> 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/listi

OO 2.2 freezes repeatedly on Freespire 2.0.8

[Kenneth Koym]

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 


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 .

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

[bug #23023] cp -r use a lot of memory, feature or memory leak?

[Matteo Boccafoli]

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:

  

___
  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

Re: [bug #23023] cp -r use a lot of memory, feature or memory leak?

[Jim Meyering]

Matteo Boccafoli <[EMAIL PROTECTED]> wrote:
> URL:
>   
>  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_1
> /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_1 # 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

Re: [PATCH] tests/cp/cp-reply: --reply only accepts valid arguments

[Jim Meyering]

"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