This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
[dev oct 19] I hope I can explain this clearly. Make yourself a new template in Options, e.g. some Java source or something, marking it as a template. The .nbattrs file on disk correctly shows: <fileobject name="whatever"> <attr name="template" boolvalue="true"/> </fileobject> Fine. Now switch template off. In code, this means setting the attribute to null. You get this: <attr name="template" serialvalue="aced0005737200316f72672e6f70656e6964652e66696c6573797374656d732e4d756c746946696c654f626a65637424566f696456616c7565d9ec9c94d5fd3ca40c0000787077040000000178"/> (probably a MFO.NullValue) This is wrong. MFO.NV is supposed to be used to explicitly mark a value which should be null, where otherwise some overriding layer in the MFS would make it non-null. But there is no other layer in the MFS providing this file: we have just created it in the user system/ folder. So instead it should simply delete the <attr> element. This would cause the value of 'template' to be null, as desired.
Definitely performance will be affected.
It's probably not important enough to justify any performance loss. I did not realize that was a factor (no longer know much about internals of MultiFileObject attr merging....).
So, I decrease priority.
Target milestone -> 3.3.1.
*** Issue 13279 has been marked as a duplicate of this issue. ***
Set target milestone to TBD
Target milestone was changed.
Added CC: dkonecny.
I have similar problem. I'm implementing reverting in Registry API. Here is my case: * a folder has an attribute which is specified in module's layer. * user deleted the attribute on SystemFS. This results in creation MFO.NullValue as Jesse mentioned. Now when I want to revert this modification I thought that I could get SESSION layer FS from Session manager and simply delete the attribute. But this does not work. The Session layer FS is another MultiFS and deletion of attribute results again in creation of MFO.NullValue. But I think I can workaround my problem. Just wanted to recorded it here.
This issue causes, that method getAttributes lists also attributes, that have null value and thus should be considered as deleted. This is particularly strange if you get FileAttributeEvent, which notifies you, that attriubute was deleted and method getAttributes list it.
Should be obsoleted by Registry anyway, of course.
This issue causes failure of validation test for new winsys. Hacking the test by commit: core/test/unit/../projects/ValidateLayerConstistencyTest.java 1.3.20.2 In case this issue is fixed, please remove that hack.
Created attachment 11884 [details] Diff of the hack applied on commit-validation test
I found when reproducing issue #115343 that when a folder is reordered, OpenIDE-Folder-Order is written as (serialized) null to $userdir/config/.nbattrs even though it was not set to begin with. Checking in FolderOrder.java; /shared/data/ccvs/repository/openide/loaders/src/org/openide/loaders/FolderOrder.java,v <-- FolderOrder.java new revision: 1.10; previous revision: 1.9 done
Reassigning to new module owner jskrivanek.
Performance may be affected by the fix.
NetBeans.org Migration: changing resolution from LATER to WONTFIX
Still broken. Created a new file on the SFS, and called setAttribute(..., null). .nbattrs then had: <attr name="..." serialvalue="aced0005737200316f72672e6f70656e6964652e66696c6573797374656d732e4d756c746946696c654f626a65637424566f696456616c7565d9ec9c94d5fd3ca40c0000787077040000000178"/> where that deserializes to MultiFileObject.VoidValue. Surely fixable somehow. Even if it cannot be handled correctly by MultiFileSystem, at least XMLMapAttrs can handle this special case.
Integrated into 'main-golden', will be available in build *201011210001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/18c6043dc69d User: Jesse Glick <jglick@netbeans.org> Log: Work around #16761 (null storage bug).
Valid? Can you write a unit test?
(In reply to comment #21) > Valid? Yes. > Can you write a unit test? core-main #ce6e92f95dbc
Integrated into 'main-golden', will be available in build *201012010001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/ce6e92f95dbc User: Jesse Glick <jglick@netbeans.org> Log: Disabled test for #16761.
ergonomics#17e9dcddf9d2
Integrated into 'main-golden', will be available in build *201103090000* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/17e9dcddf9d2 User: Jaroslav Tulach <jtulach@netbeans.org> Log: #16761: Don't store null, when previous value is also null
Integrated into 'main-golden', will be available in build *201103120400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/6984ab74084c User: Jesse Glick <jglick@netbeans.org> Log: Cleaner handling of repo persistence. 1. Use FileUtil.get/setOrder. 2. Assume fix of #16761.
Integrated into 'main-golden', will be available in build *201105111436* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/7ca066d3d98d User: Jesse Glick <jglick@netbeans.org> Log: Removing old workaround probably obsolete as of #16761.
Integrated into 'main-golden', will be available in build *201106010401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/5d20e4e7eace User: Jesse Glick <jglick@netbeans.org> Log: Removing workaround for #16761.
Related bug still open: if there was a value set in the underlying FS, clearing it via MFS stores VoidValue rather than simply null on the underlying FS: diff --git a/openide.filesystems/test/unit/src/org/openide/filesystems/VoidValueTest.java b/openide.filesystems/test/unit/src/org/openide/filesystems/VoidValueTest.java --- a/openide.filesystems/test/unit/src/org/openide/filesystems/VoidValueTest.java +++ b/openide.filesystems/test/unit/src/org/openide/filesystems/VoidValueTest.java @@ -98,6 +98,9 @@ assertEquals(Collections.emptyList(), Collections.list(baseFile.getAttributes())); assertEquals(Collections.emptyList(), Collections.list(derivedFile.getAttributes())); assertFalse(new File(getWorkDir(), ".nbattrs").isFile()); + baseFile.setAttribute("real", "whatever"); + derivedFile.setAttribute("real", null); + assertNull(baseFile.getAttribute("real")); } }
Moved into separate test, but... # This patch file was generated by NetBeans IDE # It uses platform neutral UTF-8 encoding and \n newlines. --- Base (BASE) +++ Locally Modified (Based On LOCAL) @@ -100,4 +100,17 @@ assertFalse(new File(getWorkDir(), ".nbattrs").isFile()); } + public void testVoidValue() throws Exception { + clearWorkDir(); + LocalFileSystem local = new LocalFileSystem(); + local.setRootDirectory(getWorkDir()); + FileObject baseFile = local.getRoot().createData("file"); + MultiFileSystem mfs = new MultiFileSystem(new FileSystem[] {local}); + FileObject derivedFile = mfs.findResource("file"); + baseFile.setAttribute("real", "whatever"); + derivedFile.setAttribute("real", null); + assertNull("Derived attribute nullified", derivedFile.getAttribute("real")); + assertNull("Underlaying attribute is not void", baseFile.getAttribute("real")); } + +}
ergonomics#9506f0a1f9ee
Last fix goes only to 7.1
Integrated into 'main-golden', will be available in build *201107300600* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/9506f0a1f9ee User: Jaroslav Tulach <jtulach@netbeans.org> Log: #16761: Storing null to file attr on SFS saves serialized MultiFileObject.VoidValue Don't use VoidValue when not necessary