Date:	Tue, 15 Jun 1999 10:00:27 +0300 (WET)
From:	Andris Pavenis <pavenis AT ieva01 DOT lanet DOT lv>
To:	Alain Magloire <alainm AT rcsm DOT ece DOT mcgill DOT ca>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: Wrong errno value from rename() when sharing problems under
	Win9X
In-Reply-To:	<199906150041.UAA10094@mccoy2.ECE.McGill.CA>
Message-ID:	<Pine.A41.4.05.9906150950090.35100-100000@ieva01.lanet.lv>
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

On Mon, 14 Jun 1999, Alain Magloire wrote:

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

This thing was found when I made a bug in my own program when file
errorously was left opened (now my bug is fixed). The reason of this bug
report is that we should have after some error value of errno that
as close as possible describes real error and in this case better is to
have EACCES but not ENOENT.

Imagine You are debugging program fragment:

if (access(oldName,0)==0)
  {
     if (rename (oldName,newFname)!=0)
       {
           perror ("rename");
	   return -1;
       }  
  } 

and are getting ENOENT instead of EACCES if file with name oldName is
somewhere left opened earlier. How much time will You spend to figure out
that real error code should be EACCES. 
 
> 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 .....
> 

Wincrap9X behaves so and we are not able to change this behaviour but
anyway we should have correct value of errno if something similar happens.

Andris

- Raw text -