DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:reply-to:to:subject:date:message-id
	:references:in-reply-to:content-type:content-transfer-encoding
	:mime-version; q=dns; s=default; b=u9PlGKBdsuGI3bafOv8S2SWSTiMwn
	/148RSArPmXNJkpzvSSJ7bE+s2gK0TI0B2VC93zC7r+k8HW07OatFnIJBxR0HkY7
	0/Cn2+MQguryjj5MylIAFKpw17CElc4/e88Mqa+AL0g08prrythyqhCiFgBEZhfO
	BbK2iPMVWAK8DM=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
IronPort-SDR: KwfMI4KjWvwHWU1fKH6sqU92pxXONCibYshYUCqoH7kb9TNHeV8I+wSLgD1+zEHhXX4vnFxwEy oBBCX8af7gCQ==
From: "Buchbinder, Barry (NIH/NIAID) [E] via cygwin" <cygwin@cygwin.com>
Reply-To: "Buchbinder, Barry (NIH/NIAID) [E]" <barry.buchbinder@nih.gov>
To: cygwin <cygwin@cygwin.com>
Subject: RE: non-persistent storage?
Date: Fri, 13 Dec 2019 16:17:42 +0000
Message-ID: <BYAPR09MB29010EDD6B0DA9BE871504959B540@BYAPR09MB2901.namprd09.prod.outlook.com>
References: <BYAPR09MB29010912EBAE9D8F0196D35E9B550@BYAPR09MB2901.namprd09.prod.outlook.com> <20191212220749.GB12864@tik.uni-stuttgart.de> <CACoZoo1crFaE0ZHBVZaps+F93MyX1c4MN5-5awJ=jFmEAE2vnA@mail.gmail.com>
In-Reply-To: <CACoZoo1crFaE0ZHBVZaps+F93MyX1c4MN5-5awJ=jFmEAE2vnA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-userprincipalname: 7NS60yQ+MzeFVNCQFVzGpmCilANyc1kvnvuCGb/mmKSXZhvf1kq/9tNm6pQ6CIKdhhmqExYnreINztB0GMkunA==
X-IsSubscribed: yes
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by delorie.com id xBDGLHaX012141

>On Thu, Dec 12, 2019 at 5:08 PM Ulli Horlacher wrote:
>
>>Erik Soderquist sent the following at Thursday, December 12, 2019 5:45 pm
>>
>> On Thu 2019-12-12 (21:59), Buchbinder, Barry (NIH/NIAID) [E] via cygwin wrote:
>>>
>>> If the temp file was created by mktemp and the name saved in an
>>> environmental variable, each bash shell could have its own file with
>>> not risk that an instance of bash would erase another instance's file.
>>
>> I need the opposite: all processes must read and write the same data!
>> And the data must be gone when system shuts down or even if there is a
>> power failure.
>
> This is very hacky, but I believe you can get the effect you want by
> having an admin process auto-start at host startup, identify itself, and
> then set parts of its own /proc/ process ID tree as world read/write.
> I think this will give you the "destroyed even at power failure"
> impermanence you are looking for. I know it is not in the normal
> layouts (like /var/run/ would be), but we are working around limitations
> imposed by Windows.

One could put a script, batch file, or a link thereto in one's startup
folder that will run on Windows' boot.  The script/batch file would be
written to clean out the tmp files.  Google << windows startup folder >>.
If all processes, regardless of whether they start with the same
shell/subshell, will share the same temp file, one could create the file
upon boot using the same script.

Also, one could make the script that creates the temp file (e.g.,
.bashrc) check the file or an environmental variable so that a subshell
doesn't create a new temp file, if that's how you want it.

- Barry
  Disclaimer: Statements made herein are not made on behalf of NIAID.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple