From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17486 invoked by alias); 7 Dec 2016 10:59:55 -0000 Mailing-List: contact cygwin-developers-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner@cygwin.com Mail-Followup-To: cygwin-developers@cygwin.com Received: (qmail 17183 invoked by uid 89); 7 Dec 2016 10:59:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.1 required=5.0 tests=AWL,BAYES_40,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=H*r:smtp, HTo:U*cygwin-developers, learned, H*Ad:U*cygwin-developers X-HELO: smtp.salomon.at Received: from smtp.salomon.at (HELO smtp.salomon.at) (193.186.16.13) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 07 Dec 2016 10:59:50 +0000 Received: from samail03.wamas.com ([172.28.33.235] helo=mailhost.salomon.at) by smtp.salomon.at with esmtps (UNKNOWN:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1cEZvz-00089c-Oc; Wed, 07 Dec 2016 11:59:44 +0100 Received: from [172.28.41.34] (helo=s01en24) by mailhost.salomon.at with smtp (Exim 4.77) (envelope-from ) id 1cEZvx-0001gP-Qm; Wed, 07 Dec 2016 11:58:46 +0100 Received: by s01en24 (sSMTP sendmail emulation); Wed, 07 Dec 2016 11:58:45 +0100 From: Michael Haubenwallner To: cygwin-developers@cygwin.com Subject: RFC: [PATCH 0/6] When fork fails, retry with hardlinks. Date: Wed, 07 Dec 2016 10:59:00 -0000 Message-Id: <1481108310-14825-1-git-send-email-michael.haubenwallner@ssi-schaefer.com> X-SW-Source: 2016-12/txt/msg00000.txt.bz2 Hi Corinna (et al.), now with NtQueryVirtualMemory(MemorySectionName) I've been able to drop the need to early open any file, and any check for modified binaries. Instead, only the failing fork call is the trigger to create the hardlinks (if possible) - followed by a second fork call then. One question: During dlopen rework I've learned about tmp_pathbuf: Unlike in child process startup, where tmp_pathbuf is not initialised yet (have nt_max_path_buffer instead), do you see a reason to not use tmp_pathbuf during hardlink creation in parent process (patch 3)? The idea there is to really catch the right file for when that file is just being renamed - that needs the second filename buffer to compare. Other than that: What do you think about these patches now? Thanks! /haubi/