From:	Alain Magloire <alainm AT rcsm DOT ece DOT mcgill DOT ca>
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:	<B0000090438@stargate.astr.lu.lv> from "pavenis@lanet.lv" at Jun 14, 99 04:24:03 pm
X-Mailer:	ELM [version 2.4 PL25]
MIME-Version:	1.0
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

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

- Raw text -