Add preference for disabling history on restricted files

[trancexpress]

This change adds a new preference to org.eclipse.core.resources:

disableRestrictedFileHistory

If the preference is set to 'true' and a file is restricted, setting the contents of the file will result in no new history entry for the edit.

Example preference for product customization:

org.eclipse.core.resources/disableRestrictedFileHistory=true

Fixes: #2588

[trancexpress]

Undo seems to work even without the history, so no problem with that part of editing.

[github-actions]

Test Results

    54 files  ± 0      54 suites  ±0   36m 25s ⏱️ - 1m 33s
 4 556 tests + 8   4 413 ✅ + 8   23 💤 ±0  28 ❌ ±0  92 🔥 ±0 
12 229 runs  +24  11 949 ✅ +24  159 💤 ±0  29 ❌ ±0  92 🔥 ±0 

For more details on these failures and errors, see this check.

Results for commit 2a00af3. ± Comparison against base commit dcbe8a1.

♻️ This comment has been updated with latest results.

[laeubi]

I think this can be usefull not only for sensitive information!

But making it a transient "hidden" feature does not seems appropriate, I added a comment with a suggestion and then I think we even don't need to have a preference to enable/disable it at all.

Request is out-of-scope for the issue.

[laeubi]

@trancexpress please don't dismiss my review here just because you think it is out of scope from your point of view!

This is not how Eclipse Platform development works!

[trancexpress]

@trancexpress please don't dismiss my review here just because you think it is out of scope from your point of view!

I don't think its out-of-scope, it is out-of-scope.

This is not how Eclipse Platform development works!

Blocking PRs for arbitrary reasons is also not how platform development has worked, at least not in the last 10 years.

[akurtakov]

First of all, this project produced stable platform because people working on it cared to really discuss and spend the time to view things from another angle. The fact that people don't feel the need to do that anymore is the "Root of all Evil" (tm) and I'm extremely disappointed by the level of communication lately. No technical reason matters when people don't act with the presumption that everyone involved is acting in the best interest of the project but rather that others are acting just to make it harder. At some point this might even become self full-filling prophecy!

Now to the issue itself - As per https://github.com/eclipse-platform/.github/wiki/PMC-project-guidelines#committer-disagreement-resolution I'm asking you to prepare 2 clear statements/proposals, create a poll and ask for general vote on the topic. As long as this lack of good faith communication continues we need to engage the whole community to not allow this problem to spiral down even further.

[trancexpress]

First of all, this project produced stable platform because people working on it cared to really discuss and spend the time to view things from another angle. The fact that people don't feel the need to do that anymore is the "Root of all Evil" (tm) and I'm extremely disappointed by the level of communication lately. No technical reason matters when people don't act with the presumption that everyone involved is acting in the best interest of the project but rather that others are acting just to make it harder. At some point this might even become self full-filling prophecy!

Alright, I'm sorry if I've acted in bad faith.

Now to the issue itself - As per https://github.com/eclipse-platform/.github/wiki/PMC-project-guidelines#committer-disagreement-resolution I'm asking you to prepare 2 clear statements/proposals, create a poll and ask for general vote on the topic. As long as this lack of good faith communication continues we need to engage the whole community to not allow this problem to spiral down even further.

@iloveeclipse, please take this over. I don't know what of the Advantest feature can be disclosed.

[trancexpress]

Also, are we reverting the already merged change? eclipse-platform/eclipse.platform.ui@f04b19d

If we are looking for an over-arching design, this is a part of what we need.

I've prepared a PR for this: eclipse-platform/eclipse.platform.ui#3824

[akurtakov]

FWIW, Advantest feature is irrelevant here . It's the Eclipse Platform feature that has to be discussed here and what matters to me most is the process of expressing the disagreement in an easy to understand way for every committer of the project. In the process of doing so I hope that reading/listening to each other will be the outcome as each side will have to prepare (at least) one of the options.

[trancexpress]

FWIW, Advantest feature is irrelevant here . It's the Eclipse Platform feature that has to be discussed here

I've signed an NDA, for me its not irrelevant. I'd like to write a full description and explain what is actually needed, but I'm not actually able to.

and what matters to me most is the process of expressing the disagreement in an easy to understand way for every committer of the project. In the process of doing so I hope that reading/listening to each other will be the outcome as each side will have to prepare (at least) one of the options.

Sorry, I overreacted on the merge-blocking.

[akurtakov]

FWIW, Advantest feature is irrelevant here . It's the Eclipse Platform feature that has to be discussed here

I've signed an NDA, for me its not irrelevant. I'd like to write a full description and explain what is actually needed, but I'm not actually able to.

You do not have to share anything about Advantest or under NDA. What I need from both sides is how/when/why/what Eclipse Platform benefits from such a feature implemented in the way the given side proposes.

[iloveeclipse]

I think a session property is not really sufficient.

Instead it should be stored like we do for encoding already for example:

eclipse.preferences.version=1
encoding/<project>=UTF-8
encoding//target/maven-archiver=UTF-16
encoding/testme.txt=ISO-8859-1

that way it would be relative easy to even make this available to users on the resource setting page and prevents the history even if no specialized plugin that "knows". Further it will allow to possible have wildcards for folders in a future and so on.

Whatever you have in mind seem to be a completely different feature of what Simeon was working on. Also in your case this feature will need changes in other modules like search too. Persistent resource property, similar to session is just something in low level resources API. If any IDE functionality is going to use that, it will be unavoidable to change various places outside resources plugin.

I believe you misunderstood the proposed changes and so you think about some different use case. So whatever you have in mind needs a clear use case, so far I miss to see it. Let assume there are "sensible data" (passwords? bank account information?) is saved in the project. This is against any security basics, and not something we should "hide" from local history - it should be encrypted instead. "Hiding" persisted local files from local history is nonsense - they are already on disk and there is already a way to do so without touching local history at all. Beside this, pointing to that specific file in the project properties is the hint for every "bad" actor: look, there is a sensible information stored, don't miss it!

What you probably want is not hiding files from local history or search, but hiding it completely - and there is already API and UI for that, it is resource filters and configuration dialog to do exactly that:

There is no need to reinvent the wheel. If you mean something like this but encrypted for sensible information, it would be implemented in a very similar way and it would get a similar UI.

But that is all not what we want & work on.

The use case we have in mind here is different, and doesn't require any persistent data or doesn't touch any persisted data on purpose, because it is about sensible data that is not persisted at all on disk, but exposed to user as "virtual" file system. The data is "plugged in" in resource tree on demand and exists no longer as during the current session. This works flawlessly with existing APi's and all infrastructure except few places where the "virtual" resource is persisted by IDE (unintentionally) in some way on disk, like local history.

And that is what this change about. Not introducing new UI concepts or features but limiting some existing features to read or persist data that shoulnd't be persisted.

The very nature of opensource collaboration is that there are different ideas and different viewpoints and we have all agreed as per the EDP process to be open for different things so it is natural to discuss and has often lead to better designs in the end instead of rushing in the first idea that cam in mind.

We've discussed different approaches here, so it is not the first idea:
eclipse-platform/eclipse.platform.ui#3816 (comment)

instead of rushing in the first idea that cam in mind.

This is not appropriate and offending communication style. Please avoid such language.

[laeubi]

Thank you @iloveeclipse for the detailed explanation of the actual use case.
I think I now have a much better understanding of what you're solving: virtual files that exist only during a session and must not leave traces on disk.

I accept that persistent preferences (like encoding) are not the right fit for this — the data is session-scoped by nature, so the mechanism should be too.

However, I still have a concern about the architectural pattern, not the persistence model.

The problem I see

Right now the same pattern is being replicated independently across multiple plugins:

• org.eclipse.core.resources/disable_history_property → skip local history
• org.eclipse.search.core/search_exclusion_property → skip search indexing
• eclipse.jdt.core (planned, #4970) → skip JDT indexing

Each plugin reads its own preference, resolves it to a session property name, and checks resource.getSessionProperty(...) independently.
This works, but:

• Every new subsystem that needs this must reinvent the same boilerplate.
• Client code must configure N preferences to fully protect a file.
• There is no discoverable API — integrators have to know about each hidden preference.
• If the property name isn't kept in sync across preferences, files get partial protection.

---

@akurtakov here is my proposal as requested

---

I'd like to propose the two options for the community vote as follows:

Option A — Per-plugin preferences (current PR approach):
Each plugin defines its own preference whose value names a session property.
Subsystems check independently. Client configures N preferences and sets 1 session property.
Minimal change per subsystem, no new API.

Option B — Centralized session-based mechanism at the resources level:
A single well-known concept at the IFile level (e.g. a method like isContentRestricted() backed by a single session property) that all subsystems query.
One property to set, one concept to learn, self-documenting through API.
This is conceptually similar to what @iloveeclipse originally proposed in the PR #3816 discussion before the per-plugin approach was adopted.

I believe Option B benefits Eclipse Platform more because:

• It provides a clean, discoverable contract for all current and future subsystems.
• It reduces the burden on integrators (set one property instead of configuring N preferences).
• It follows the spirit of existing resource-level concepts like isDerived() and isHidden().
• It scales naturally as more subsystems need to respect the flag.
• It would be possible to enhance the concept to persisted resources as well if ever found useful

[iloveeclipse]

I believe Option B benefits Eclipse Platform more

We've discussed with Simeon this before and we haven't heard any other opinions, so it was 1:1 and Simeon's proposal won. Now with your vote we have 1:2 for the Option B, so let follow this path, outlined in eclipse-platform/eclipse.platform.ui#3816 (comment).

In IFile interface following would be added (with proper javadoc etc of course):

	/**
	 * Session property used to mark a file as containing restricted content
	 * 
	 * @since 3.24
	 */
	QualifiedName RESTRICTED_CONTENT = new QualifiedName(ResourcesPlugin.PI_RESOURCES, "restrictedContent"); //$NON-NLS-1$

	/**
	 * Returns whether the current file is marked as containing restricted
	 * (sensible) content, where some IDE functionality related to the file content
	 * might be limited.
	 * 
	 * @return whether the current file is marked as containing sensible content.
	 *         This flag is not persisted and is false by default.
	 * @since 3.24
	 */
	default boolean isContentRestricted() throws CoreException {
		return getSessionProperty(RESTRICTED_CONTENT) != null;
	}

	/**
	 * Marks the current file as containing restricted (sensible) content. Some IDE
	 * functionality related to the file content might be limited as long as the
	 * file is marked as restricted. This flag is not persisted and is false by
	 * default.
	 * 
	 * @since 3.24
	 */
	default void setContentRestricted(boolean restricted) throws CoreException {
		setSessionProperty(RESTRICTED_CONTENT, Boolean.toString(restricted));
	}

I think we can discuss further details of wording etc on the PR. Already merged changes can be easily adopted to use the proposed API.

[trancexpress]

@iloveeclipse one of your requirements was having a preference and reading the session property only if the preference is set - to avoid overhead for when the session property is not needed.

Does that stay and if so, what is the name of the preference?

[merks]

A general comment. The word sensible in German does not mean the same thing as word sensible in English where that English word is probably better translated to the German word sinnvol. You should use the word sensitive as the translation in the documentation that I see...

[iloveeclipse]

one of your requirements was having a preference and reading the session property only if the preference is set

Good point. To be precise, the requirement was that the "normal" workspace / IDE work shouldn't be affected / there shouldn't be measurable performance impact for existing applications, and the implied solution was to guard that by a preference that can be set/unset at runtime. For the name: if it would be preference, it would be in the resources bundle, value something like enableRestrictedContentSupport. But then the implementation would go into the File, the IFile would have only default method stubs doing nothing.

Another possibility (no storage based) would be to have new state exposed as API (via IWorkspace.isRestrictedContentSupportEnabled() + setter), which would avoid using preference store completely and IFile default methods could have full implementation, because iFile has always access to the getWorkspace().

A general comment. The word sensible in German does not mean the same thing as word sensible in English

Thanks, that all sounds same to me, being native russian :-).

[trancexpress]

Considering there are votes in favor of new API, what about adding a new flag, like the derived flag?

1. For the history change here, the code already checks the derived flag - it can fetch all the flags and that won't change performance noticeably.
2. For the text search, TextSearchVisitor.TextSearchJob.processFile() will call Resource.exists() during TextSearchRequestor.acceptFile(IFile) - before the file is processed. Here we would be adding one more flag check on top of this, which is probably not much.
3. I'm not sure about the Java indexer, but there I'm also not sure if we continue with the change (due to evolving requirements).

[iloveeclipse]

what about adding a new flag, like the derived flag?

Such flags are usually persisted in the workspace tree, but we use session property / no need to "touch" workspace.

[trancexpress]

I assume the current voting is:

In favor of adding APIs to support #2588:

• @iloveeclipse
• @laeubi

In favor of the preference approach:

• @trancexpress

So I've opened a PR where we can discuss and add the API: #2597

Interested contributors please add yourselves to the review list, I've added only @iloveeclipse and @laeubi.

Once the API is added, we can continue here using it. As well as adjust: eclipse-platform/eclipse.platform.ui#3815

[trancexpress]

OK, lets continue here.

One question is, do we want to control the history disabling with a preference? Currently the change has this.

If we do want this, what is the default value for the preference?

I assume we want the same for the other places we need to disable?

• Provide options for disabling file search on some files eclipse.platform.ui#3815
• Add preference for disabling indexing of specific files eclipse-jdt/eclipse.jdt.core#4970

[iloveeclipse]

If we do want this, what is the default value for the preference?

Yes, we want preference, default would be "don't check for restricted content", we don't want affect resources performance by default. Whoever wants checks must enable them explicitly.

[trancexpress]

Yes, we want preference, default would be "don't check for restricted content", we don't want affect resources performance by default. Whoever wants checks must enable them explicitly.

@laeubi please provide feedback on this when you can.

[Copilot]

Pull request overview

Adds a new org.eclipse.core.resources preference (disableRestrictedFileHistory) intended to prevent local history entries from being created when editing content-restricted files, addressing eclipse-platform issue #2588 about avoiding disk persistence of sensitive workspace content.

Changes:

• Introduces a new core-resources preference check in FileSystemResourceManager#storeHistory to skip history for restricted files when enabled.
• Hooks preference change listening to update the behavior at runtime.
• Adds a new JUnit test suite (DisableHistoryTests) and wires it into AllLocalStoreTests.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 5 comments.

File	Description
resources/bundles/org.eclipse.core.resources/src/org/eclipse/core/internal/localstore/FileSystemResourceManager.java	Adds preference-backed suppression of local history for content-restricted files and listens for preference changes.
resources/tests/org.eclipse.core.tests.resources/src/org/eclipse/core/tests/internal/localstore/DisableHistoryTests.java	New tests validating that restricted files don’t create new history entries when the preference is enabled.
resources/tests/org.eclipse.core.tests.resources/src/org/eclipse/core/tests/internal/localstore/AllLocalStoreTests.java	Registers the new test class in the local store test suite.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[iloveeclipse]

@laeubi : please re-review or remove negative review on this PR.

[iloveeclipse]

LGTM.

[iloveeclipse]

Dear reviewers, please review. I plan to submit it tomorrow.

[iloveeclipse]

@laeubi : please re-review or remove negative review on this PR.

Last reminder, please re-review. I plan to merge today.

[akurtakov]

Cursory read only - nothing obvious to block inclusion from my side.

Original review was based on completely different code, reviewer not responding to review updated code.

[iloveeclipse]

Test failures are likely caused by recent update of ant (see eclipse-platform/eclipse.platform.releng.aggregator#3741) and are unrelated:

Failed to execute goal org.eclipse.tycho:tycho-surefire-plugin:5.0.3-SNAPSHOT:test (default-test) on project org.eclipse.ant.tests.ui: There are test failures.

I've created #2605

[iloveeclipse]

I've created #2605

There are even more ant errors on Windows, but all unrelated to this PR. Merging.