Mailing-List: contact cygwin-help@sourceware.cygnus.com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@sources.redhat.com Delivered-To: mailing list cygwin@sources.redhat.com Date: Tue, 31 Oct 2000 22:47:30 +0300 From: Egor Duda X-Mailer: The Bat! (v1.45) Personal Reply-To: Egor Duda Organization: DEO X-Priority: 3 (Normal) Message-ID: <13241044869.20001031224730@logos-m.ru> To: Jason Tishler CC: cygwin@sources.redhat.com Subject: Re: autoheader (mv/exec) problem In-reply-To: <20001031100701.B1441@dothill.com> References: <20000823231923.A16518@OLMY> <20001031100701.B1441@dothill.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi! Tuesday, 31 October, 2000 Jason Tishler Jason.Tishler@dothill.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@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19 -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe@sourceware.cygnus.com