This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Bug in rm -r with locked files


YES!!!!!!!!!  I too concur BIG TIME! In fact, I do not use rm -r in my
scripts because of this problem. In perl scripts I use the Windows command
$output=`cmd /c del /s *.* > 2>&1` (or similar) and examine the output for
ACCESS DENIED, where I can then do an attrib and continue.

ANDDDD ......... since we're on the topic of rm .... I have spent a limited
amount of time trying to isolate a NASTY memory leak in NT4.0 SP6 when running
commands via telnet. I have 512 MB of ram and if do a lot of rm's or ls -sh
over a telnet connection, I can actually deplete the memory till the box locks -
usually in as little as 20 minutes. I haven't reported this problem till now
because without more specifics, my experience has been that such posts usually
end up being ignored. And specifics take time and effort to isolate and enumerate.
But, since rm is the topic, I thought I'd piggy-back this issue in case someone
actually does take the time to poke around the source code. In that vein, I've
attached an "overlooked" (or ignored - I expect a "MEAN" response for this -
so FIRE AWAY! \\-> ((o))  ;-) )  post from the archives that addresses an
rm memory leak. I tested it a couple of days ago and YEP - it's still there!!!

Brian Kelly

###########################################################

> memory leak? (was: 1.3.9: "fork: Permission denied" (Windows 2000))
> From: "Reddie, Steven" <Steven dot Reddie at ca dot com>
> To: cygwin at cygwin dot com
> Date: Thu, 28 Feb 2002 15:30:26 +1100
> Subject: memory leak? (was: 1.3.9: "fork: Permission denied" (Windows 2000))

> --------------------------------------------------------------------------------

> There's a memory leak, but I can't work out what is causing it.  None of the
> processes in Task Manager own up to it, so does that mean it's the OS?

> I have been able to reproduce this leak using the scripts included below.
> mkfiles creates 1000 files.  rmfiles removes those 1000 files.  Executing
> mkfiles results in about 5MB being leaked, whilst rmfiles leaks about 30MB
> each time.  Below are stats from the Performance tab of Task Manager whilst
> running these scripts.  Handles don't seem to be leaked.

> It takes about 4 seconds to create the 1000 files, but about 70 seconds to
> remove those 1000 files.  Does this seem normal?

> Time    Handles, Available Physical Memory, Total Commit Charge
> 2:00    3870, 149.4M,  95.9M    Before running mkfiles
> 2:05    3719, 143.1M,  97.5M    Before running rmfiles
> 2:10    3679, 115.4M, 125.4M    Before running mkfiles
> 2:15    3673, 110.4M, 130.0M    Before running rmfiles
> 2:20    3661,  80.7M, 159.6M    Before running mkfiles
> 2:25    3689,  76.5M, 163.6M    Before running rmfiles
> 2:30    3686,  49.4M, 191.1M    Before running mkfiles
> 2:35    3718,  44.9M, 194.1M    Before running rmfiles
> ./rmfiles: line 5: 30312 Segmentation fault      (core dumped) rm -f
> files/file$a
> 2:37    3717,  16.3M, 222.6M    After running rmfiles

> After this, I ran each of the commands again.  rmfiles failed with an error
> message simiar to the following.  This following error message was displayed
> when trying to open a new bash window after this failure:
>       0 [main] bash 28900 sync_with_child: child 37868(0x1A8) died before
> initialization with status code 0x80
>    6476 [main] bash 28900 sync_with_child: *** child state waiting for
> longjmp
> bash: fork: Resource temporarily unavailable

> This appears to be the same problems as I was getting whilst doing a
> recursive make.
> NOTE: I don't get this problem on my desktop, only on the notebook, but then
> I was only getting the recursive make problem on the notebook.  If anyone
> out there is also having the recursive make or "fork: Permission denied"
> problems could you please try running these scripts and watching the stats
> in the Performance tab of Task Manager.  It would be good to know if this is
> just me (maybe corrupt Windows 2000), or a more common problem.

> Regards,

> Steven


> mkfiles
> =======
> #!/bin/bash
> mkdir files
> for ((a=0; a<1000; a++)) do
>         echo foo > files/file$a
> done


> rmfiles
> =======
> #!/bin/bash
> for ((a=0; a<1000; a++)) do
>         rm -f files/file$a
> done
> rmdir files

##################################################################


> Yep, I concur.  If windows has a lock on the file, rm just hangs.  I've
> seen it hang on directories when doing an 'rm -rf yada/*"

>> On Tue, 2003-01-21 at 06:50, Gael Mulat wrote:

>>     Hi,
>>
>>     This is a bug report about rm (package fileutils, version 4.1-1) on
W2K.
>>
>>     Test case: take 2 cygwin shells.
>> shell 1:
>>     mkdir /tmp/directory
>>     vi /tmp/directory/file
>>
>> shell 2:
>>     /bin/rm -rf /tmp/directory
>>
>>     The shell2 doesn't manage to remove the directory and goes into an
>> infinite loop, taking 100% of the CPU.
>>     All is then OK if we go out of vi in the shell1.
>>
>>     Doing the same thing (deleting the directory) directly in Windows
>> produces an error message: "cannot delete directory: Access is denied.
>> The source file may be in use" and we can notice in the directory a file
>> named .file.swp that is also visible under Cygwin with ls -la.
>>
>>     The example I have just given uses vi, but it is the same with all
>> processes that open the file, as W2K puts a lock on it.
>>
>> Gael Mulat
>>








"Empire Health Choice Inc." made the following
 annotations on 01/21/2003 08:30:31 AM
------------------------------------------------------------------------------

[INFO] -- Access Manager:
Attention!  This electronic message contains information that may be legally confidential and/or privileged.  The information is intended solely for the individual or entity named above and access by anyone else is unauthorized.  If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful.  If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement




--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]