From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18104 invoked by alias); 21 Jun 2009 23:17:06 -0000 Received: (qmail 18093 invoked by uid 22791); 21 Jun 2009 23:17:06 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from fencepost.gnu.org (HELO fencepost.gnu.org) (140.186.70.10) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 21 Jun 2009 23:16:59 +0000 Received: from eliz by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1MIWHQ-00010J-Ns; Sun, 21 Jun 2009 19:16:56 -0400 From: Eli Zaretskii To: "Pierre Muller" CC: pedro@codesourcery.com, gdb-patches@sourceware.org In-reply-to: <000301c9f28f$aa284220$fe78c660$@u-strasbg.fr> (muller@ics.u-strasbg.fr) Subject: Re: [RFA] testsuite/gdb.base/fullname.exp fix Reply-to: Eli Zaretskii References: <000501c9f12b$68c860e0$3a5922a0$@u-strasbg.fr> <200906210227.48175.pedro@codesourcery.com> <000301c9f28f$aa284220$fe78c660$@u-strasbg.fr> Message-Id: Date: Sun, 21 Jun 2009 23:17:00 -0000 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-06/txt/msg00554.txt.bz2 > From: "Pierre Muller" > Cc: > Date: Sun, 21 Jun 2009 18:45:18 +0200 > Content-Language: en-us > > OK, now I understand: > bfd seems to use these special flags, Actually, it probably doesn't. See below. > so that after putting a breakpoint on main > you end up with two open handles on the executable > (I found that out by debugging gdb with itself) > and if you issue: > (gdb) shell rm gdb.base/fullname.exe > All works, in the sense that you are able to > delete the file despite the open handles. > But the problem is that if you try that: > (gdb) shell echo dummy > gdb.base/fullname.exe > you get: > sh: gdb.base/fullname.exe: Permission denied. > > So when trying to recompile fullname.exe > GNU ld first erases the existing binary (=> success) > and later tries to write the new binary (=> failure). > > What is the use of allowing delete operation and not write operation? That is all in the flags used when opening the file. With the right flags, write will also be permitted. But I think for that we will need our own emulation of `open' and friends, because the one in the Windows runtime doesn't use them. And even then, what NTFS does is not fully Posix compliant: for example, the deleted file is still visible in the filesystem, as long as at least one program has an open handle for it, try running `ls' and you will see it. So, on balance, I'd suggest to fix the testsuite not to expect this Posix semantics, at least not on DOS/Windows.