Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 334508 - Need to determine that the platform's working directory was created during the current session
Summary: Need to determine that the platform's working directory was created during th...
Status: RESOLVED WONTFIX
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Runtime (show other bugs)
Version: 3.7   Edit
Hardware: PC All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: platform-runtime-inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 364140
  Show dependency tree
 
Reported: 2011-01-17 06:14 EST by Szymon Brandys CLA
Modified: 2011-11-18 06:56 EST (History)
6 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Szymon Brandys CLA 2011-01-17 06:14:59 EST 
I need to determine somehow that the platform's working directory (also known as the instance data area) was created during the current session. In other words I need to check that my Eclipse is not using an existing workspace, but has just created one.

I was chatting with Dj about .metadata/version.ini. I thought that the code creating the file could also set a flag indicating that the worksapce is new. I found that IDEApplication#checkInstanceLocation creates it, so we can't rely on that. We should set the flag somewhere in the core code. Maybe BasicLocation?
Comment 1 DJ Houghton CLA 2011-01-20 10:36:42 EST 
Tom, let's chat about this when you get back.
Comment 2 John Arthorne CLA 2011-01-20 11:22:52 EST 
I'm not convinced this is going to do the right thing. For example if you never do any team operations in the very first session, then you will never be aware that the workspace is new. Consider the following example:

1) Installer invokes "eclipse -initialize" to complete the install. Workspace gets created and eclipse immediately exits.
2) Product is started by the user. At this point it is not a "new" workspace because the initialize step already created it.
Comment 3 Szymon Brandys CLA 2011-02-23 08:33:51 EST 
Tom, any comment on it?
Comment 4 Thomas Watson CLA 2011-02-23 11:05:16 EST 
(In reply to comment #3)
> Tom, any comment on it?

I think this approach is incorrect.  A location can get locked from an external source that never runs team stuff or even the workbench.  Imagine some tool that provisions projects to a new workspace.  It would first try to lock the new workspace which creates the location, then lock it and then create projects for it.

The first time you launch with such a workspace you will not know it is new.  I am not sure I understand the need to know it is new.  Seems like you can set your own flag to determine that you have migrated or read your own settings.
Comment 5 Thomas Watson CLA 2011-04-29 08:54:17 EDT 
I'm closing this as wont fix.  I don't think the locking code is the correct place to put this kind of logic.