On 19 January 2011 17:38, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Of course. Â But the IDE should be smart enough to prevent disaster.
on linux, if there is no proper exclusive write-file locking supported through primitives, one could always create a .lock file and put a process id there. so before opening a .changes file for writing any image first should check if there are a .lock file and if value stored in it has same proc id as currently running one. and after closing .changes file it should delete .lock file. oh.. except that probably there is no way to obtain process id .. there is no such primitive if i remember correctly. Not a big deal.. you can use a GUID generated at image startup time to obtain same effect. But all this logic can be implemented in image.
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Yanni Chiu [yanni@rogers.com] Sent: Wednesday, January 19, 2011 11:22 AM To: pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Any Clue..
On 19/01/11 8:48 AM, Schwab,Wilhelm K wrote:
Sig,
Are we discussing the same OS? Â What you are describing matches my experience on Windows; on Linux, AFAIK, one can just stomp all over the files and leave a mess. Â Perhaps something has changed to make it safer since I last trashed an image that way.
I agree that there are times when it does not matter, so any safety mechanism needs to be optional, or better yet tied to a development session vs. a deployed session.
Bill
I run a common .image file that is interpreted multiple times with a different start up script. There is no .changes file. This works on MacOSX and Ubuntu. This is the behaviour I want to have, so such a "safety mechanism" would definitely need to be optional.
-- Yanni
-- Best regards, Igor Stasenko AKA sig.