Mail Archives: cygwin-developers/2001/08/04/15:54:34
On Sat, Aug 04, 2001 at 09:48:43PM +0200, Corinna Vinschen wrote:
>On Sat, Aug 04, 2001 at 02:43:07PM -0400, Christopher Faylor wrote:
>> On Sat, Aug 04, 2001 at 02:09:19PM -0400, Charles Wilson wrote:
>> >Chris Faylor wrote:
>> >>>Ok. We seem to be slowly zeroing in on the problem. Is someone willing
>> >>>to debug what's going on? Why are the files deleted with
>> >>>VFORK/no-vfork?
>> >>>
>> >>>Has anyone tried turning off VFORK in cygwin and seeing if that solves
>> >>>the problem, too?
>> >>>
>> >>>We need to understand what mechanism is not being triggered to delete these
>> >>>files.
>> >>
>> >>
>> >> Anyone working on this? I'd like to make a new release someday and this
>> >> should obviously be fixed.
>> >>
>> >> It would be wonderful if I didn't have to actually load the newest version
>> >> of autoconf on my system and debug this after all of the previous debugging
>> >> attempts.
>> >
>> >
>> >Oops. It dropped off my radar screen. I'll try to take a look, but I'm
>> >running out of time. At the risk of sounding like Bobby, Jr. <g>:
>> >
>> >My main development machine (a laptop) has had a mechanical failure, so
>> >I have to ship it off to Dell for repair on Monday. It looks like I'll
>> >be dead in the water for about a week after that. I will have email
>> >access(*) via other machines, but none of those are setup for cygwin
>> >devel. Or for LaTeX dissertation editing, for that matter. :-(
>>
>> I've been having some system problems too. That plus my "real job" have
>> limited my cygwin involvement slightly.
>>
>> It seems like Corinna has tracked this down to a potential problem with
>> vfork but I don't really understand what that is. It could well be a
>> problem with ash's use of vfork, too.
>
>Being low on time is a general problem currently, I assume. I undertook
>some halfhearted attempts to find the reason but to no avail.
>
>I guess you're right. It's probably the way ash uses vfork(). The
>interesting thing is that I even couldn't find the corresponding
>unlink()/rmdir() calls on the affected temp directories in the strace
>outputs.
>
>Strange enough, there _are_ actually `rm -rf' calls in the strace for
>some temporary directories but the concerned directories are actually
>erased. `rm' is never called for the not erased directories for some
>reason.
>
>If it's a problem with vfork() I would expect _failing_ unlink() calls
>due to still opened handle on files or similar. The fact that there
>are no unlink()s at all points to the vfork() usage in ash bypassing
>some important code.
>
>OTOH, it could also be the vfork() resulting in bypassing some
>important code...
I thought that you saw stat calls for the files to be deleted and that
the stat calls were returning ENOENT. That led me to believe that rm
was probably checking if the file exists before calling unlink().
cgf
- Raw text -