From: Alain Magloire Message-Id: <199906150041.UAA10094@mccoy2.ECE.McGill.CA> Subject: Re: Wrong errno value from rename() when sharing problems under Win9X To: djgpp-workers AT delorie DOT com Date: Mon, 14 Jun 1999 20:41:01 -0400 (EDT) In-Reply-To: from "pavenis@lanet.lv" at Jun 14, 99 04:24:03 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk Bonjour > > Rename returns invalid value in errno under Win95 when attempting > to rename already opened file (I got ENOENT, should be > EACCES). Test example included in attachment. ?? I thought, according to an old thread in this list, you could not do fd=open("file",..);unlink("file");read(fd,...); They were many scenarios discuss to emulate this but one thing they were lacking is that the file was still visible in the file system namespace. Let me refresh memories with a quote : "If a Un*x process deletes a file still open, the kernel simply marks the file for deletion and removes its entry from the parent directory. Althought no new processes can now open this file, those that have it open can continue to access it. When the last process that has the file open closes it, the kernel physically deletes the file. " The same problem happens with NFS, where the server does not know about open files. So this is emulate on the client side where an unlink() on an open file is change to a rename() operation. The client renames the file to a long random name and only sends the remove() when the file is last close. So if one can rename() open files ..... -- alain