Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Message-Id: <4.3.1.2.20010913125230.03027388@pop.ma.ultranet.com>
X-Sender: lhall AT pop DOT ma DOT ultranet DOT com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Thu, 13 Sep 2001 12:53:36 -0400
To: "Mark Paulus" <commpg AT yahoo DOT com>, "cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com>
From: "Larry Hall (RFK Partners, Inc)" <lhall AT rfk DOT com>
Subject: Re: mv implemented as cp?!?!?!!? - problem!!
In-Reply-To: <200109131647.MAA27284@acestes-fe0.ultra.net>
References: <4 DOT 3 DOT 1 DOT 2 DOT 20010913123136 DOT 02f5aed8 AT pop DOT ma DOT ultranet DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Hm, perhaps an inspection of the underlying code in Perl that's involved 
in the operations you described may provide some insight.

Larry


At 12:47 PM 9/13/2001, Mark Paulus wrote:
>Unfortunately, it looks like it's a very tight timing issue.  If I put a 
>system ("ls -ld foo tarballname"); inbetween the rename and rmdir
>statement, depending upon the system state, it may or may not be
>just enough of a delay to cause the script to work or fail.  Which
>is why I think it's an atomic function issue, and debugging is very hard.
>Kind of like finding a NULL pointer problem.  The very act of 
>putting printf debug statements into the code is usually enough to
>move the problem around, and make it hard as heck to find.
>
>
>On Thu, 13 Sep 2001 12:36:05 -0400, Larry Hall \(RFK Partners, Inc\) wrote:
>
> >Hi Mark,
> >
> >You're best bet for finding a solution to this problem is to debug Perl.
> >This will give you the details you need to know how to proceed with a 
> >proper solution.  Certainly it is Perl that is controlling the behavior
> >in this case.  It may be possible to fix or override that behavior, but
> >you'll need to find the right place to make it happen.
> >
> >Larry Hall                              lhall AT rfk DOT com
> >RFK Partners, Inc.                      http://www.rfk.com
> >118 Washington Street                   (508) 893-9779 - RFK Office
> >Holliston, MA 01746                     (508) 893-9889 - FAX
> >
> >
> >
> >At 12:26 PM 9/13/2001, Mark Paulus wrote:
> >>This brings up an interesting issue.  I'm not sure where the problem
> >>lies, or who is responsible for which piece but I will try to describe this
> >>as cohesively and clearly as I can.  
> >>
> >>On my win2K box using FAT32, I have a perl script that does the following:
> >>create a temp directory - foo
> >>does a tar extract of  tarballname into foo/tarballname
> >>rename foo/tarballname tarballname    
> >>rmdir foo
> >>
> >>Now, it appears that if the directory structure under tarballname is
> >>sufficiently large, the rename command is not actually completed 
> >>before control is returned to the perl script, and rmdir foo is invoked.
> >>This causes rmdir foo to fail with a Permission Denied error.  However,
> >>after the script runs, foo is empty.  And if I place a sleep(1) between
> >>the rename foo... and rmdir foo, the script completes successfully.
> >>
> >>Thinking about this as I write it, it seems to me that whatever is happening
> >>in the rename() perl command, it is not being handled as an atomic unit,
> >>and control is returning to the perl script before the system has actually
> >>completed the rename operation.
> >>
> >>Is there some system switch that controls when/how control is returned
> >>in these types of scenarios, as adding random sleeps is neither precise
> >>enough, nor is it even preferred?
> >>
> >>
> >>
> >>On Wed, 12 Sep 2001 21:24:39 -0400, Matthew O. Persico wrote:
> >>
> >> >"Gerrit P. Haase" wrote:
> >> >> 
> >> >> Matthew O. Persico schrieb am 2001-09-12, 18:52:
> >> >> 
> >> >> >I have a /usr/X11R6 directory that I wanted to get out of the way. So I
> >> >> >renamed it like this:
> >> >> >
> >> >> >cd /usr
> >> >> >mv X11R6 X11R6.XFree.4.1.0
> >> >> >
> >> >> >It is taking multiple minutes. Looking at it in Windows Explorer, I see
> >> >> >both X11R6 and X11R6.XFree.4.1.0 in existance at the same time.
> >> >> >
> >> >> >Is mv implemented as cp and del?!?!. Why not just rename the file, a'la
> >> >> >UNIX, or even Windows? Or am I really missing something?
> >> >> 
> >> >> It works as you would expect, but only if there is no file opened in the
> >> >> dir you want to rename.
> >> >> You can try this.
> >> >> Create a dir and fill it up.
> >> >> Make sure that there is no file opened and you're not looking in any
> >> >> subdirectory with explorer or another shell window.
> >> >> Then rename it.
> >> >
> >> >Wow. Who knew? Obviously not me. I have to see how UNIX (solaris 2.6 in
> >> >partcular) behaves when I get back to work tomorrow.
> >> >
> >> >-- 
> >> >Matthew O. Persico
> >> >New York City - we're still here.
> >> >
> >> >--
> >> >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/
> >>
> >>
> >>
> >>
> >>--
> >>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/
>
>
>
>
>--
>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/


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