Mail Archives: djgpp/2009/05/31/02:29:14

X-Authentication-Warning: mail set sender to djgpp-bounces using -f
X-Recipient: djgpp AT delorie DOT com
Date: Sun, 31 May 2009 09:27:14 +0300
From: Eli Zaretskii <eliz AT gnu DOT org>
Subject: Re: Using rename() with files still opened.
In-reply-to: <>
X-012-Sender: halo1 AT inter DOT net DOT il
To: djgpp AT delorie DOT com
Message-id: <>
References: <4cc1f101-88b2-4cda-a7b5-b01eaa9a77bf AT c9g2000yqm DOT googlegroups DOT com>
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

> From: Juan Manuel Guerrero <juan DOT guerrero AT gmx DOT de>
> Date: Sat, 30 May 2009 13:51:40 -0700 (PDT)
> The goal is to rename the source file into the target file.  With
> DJGPP's rename() and _rename() functions this fails because the
> target file is still open.  Of course, if the line: target_file =
> fopen(target_file_name, "rt"); is removed then the codes works
> flawlessly.  An inspection of _rename.c shows that function 0x7156
> cannot rename the still opened target file.  After failing _rename
> tries a second time but before it tries to remove the target file
> but this also fails to due to the same reasson, so the whole
> function does not work very well in this particular case when the
> target file has not been closed before the function call has been
> issued.  On my linux box the code snippet works no matter if the
> target file to be replaced by the source file has been closed or
> not.  Now the question arises if this is a bug or a feature?

As DJ points out, this is a ``feature'' of the underlying filesystem.
It works on GNU/Linux (and on all other Posix systems) because of the
special feature in Posix filesystems, which makes such a file
invisible to other programs under the old name, but does not actually
delete/rename it until the last handle that has the file open is

(Btw, on NTFS, the DJGPP function should work, because NTFS behaves
like Posix filesystems in this regard.  But DJGPP cannot assume NTFS.)

> For some reason I have still not fully understood, sed does not
> fclose the input file before trying to replace it with the output
> file.

The reason, no doubt, is that Sed assumes a Posix filesystem.  Such
assumptions are unportable, but many GNU maintainers are unwilling to
go an extra mile to stop assuming them, sometimes claiming that this
technique makes the file private to the application, and therefore all
kinds of complications, such as if another application writes into the
same file, cannot happen.

> The question arises if _rename() shall be modified in such a way that
> the file corresponding to the new file name is fclose/closed before
> trying to replace it with the old file.

I don't think this is a good idea.

I suggest to fix Sed, either as a DJGPP-specific patch or, if the
maintainer agrees, as a more portable code that doesn't assume Posix

- Raw text -

  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019