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
Date: Tue, 31 Oct 2000 22:47:30 +0300
From: Egor Duda <deo AT logos-m DOT ru>
X-Mailer: The Bat! (v1.45) Personal
Reply-To: Egor Duda <cygwin AT sources DOT redhat DOT com>
Organization: DEO
X-Priority: 3 (Normal)
Message-ID: <13241044869.20001031224730@logos-m.ru>
To: Jason Tishler <Jason DOT Tishler AT dothill DOT com>
CC: cygwin AT sources DOT redhat DOT com
Subject: Re: autoheader (mv/exec) problem
In-reply-To: <20001031100701.B1441@dothill.com>
References: <20000823231923 DOT A16518 AT OLMY> <20001031100701 DOT B1441 AT dothill DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi!

Tuesday, 31 October, 2000 Jason Tishler Jason DOT Tishler AT dothill DOT com wrote:

>> When running autoheader, I kept getting error messages like the
>> following:
>> 
>>     mv: cannot move `autoh16138' to `config.h.in': Permission denied
>> 
>> But after autoheader exited, I could successfully execute:
>> 
>>     mv autoh16138 config.h.in
>> 
>> without any problems.
>> 
>> By reading the (shell script) source to autoheader, I determined that
>> the problem has to do with trying to move a file when it is still open
>> -- which is no surprise since Cygwin is sitting on top of Windows...
>> 
>> The attached shell script exhibits the above problem on Cygwin but works
>> on Linux.  I'm not sure if this one is fixable...

JT> Just in case someone is still interested, I have more information
JT> regarding this problem.  The move problem only occurs on shares (i.e.,
JT> CIFS) and not on local (i.e. NTFS) file systems.

it's a feature. it's possible to deal with it in the manner similar to
"deleting  opened files" deferred delete mechanism used in cygwin. But
there's  one  important  thing about rename() which makes it different
from  unlink(). imagine we've called rename(file1,file2) when file1 is
opened.   cygwin  can put this operation in queue to perform later, or
copy  file1  to  file2 first and then perform unlink(file1). the first
way   is   bad   because   the   same  process  can assume that he can
already   use  file2  after  rename().  The   second   way   requires
additional space on disk.

i've  seen  this problem only on autoheader too, and believe that it's
simpler to "fix" autoheader.

Egor.            mailto:deo AT logos-m DOT ru ICQ 5165414 FidoNet 2:5020/496.19



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com