Hi!

This is a very strange bug and IMHO with a very big spread all over the NetBeans platform configurations. 

If you read an attribute twice you get first a changed attribute. With the second read you get the standard attribute value from the layer file. 

This issue kills many scenarios to use the SystemFileSystem with MultifileSystem as a changeable registry. More, the problem appears only randomly (if the developer needs to read the attribute twice and the user have changed the attribute).

Here an example.

A sample entry in the layer.xml:

<filesystem>
    <folder name ="org-sepix">
      <folder name= "Panes">
            <file name="Demo.txt">
                <attr name="position" intvalue="100"/>
            </file>
      </folder>
    </folder>
</filesystem>

and a minimized example class:

public class Demo {
  public static void demo () {
    FileObject folder = FileUtil.getConfigFile("org-sepix/Panes/");
    
    for (FileObject fileObject : folder.getChildren()) {
      try {
        System.out.println(fileObject.getNameExt());
        System.out.println("position = " + fileObject.getAttribute("position") + " should 100");
        
        fileObject.setAttribute("position", new Integer (200));
        System.out.println("position = " + fileObject.getAttribute("position") + " should 200");
        
        // Here the problem:
        System.out.println("position = " + fileObject.getAttribute("position") + " should 200");
        
        
      } catch (IOException ex) {
        Exceptions.printStackTrace(ex);
      }
    }
  }
}

And this is the output:

Demo.txt
position = 100 should 100
position = 200 should 200
position = 100 should 200


The last line is the wrong output.

This is reproducible with all attributes. It's hard to debug, the debugger also changes the value. 

IMHO it's a special coded block to optimize reads for attributes in the MultiFileObject class:

  private final Object getAttribute(String attrName, String path) {
        // Look for attribute in any file system starting at the front.
        // Additionally, look for attribute in root folder, where
        // the relative path from the folder to the target file is
        // prepended to the attribute name, all separated with slashes.
        // This search scheme permits writable front systems to set file
        // attributes on deeply buried files in back systems without
        // actually creating copies of the files or even their parent folders.
        // [PENDING] consider the effects of mask files
        String prefixattr = ((path.length() == 0) ? null : (path.replace('/', '\\') + '\\' + attrName));

        { /*There was proved that this block enhances performance*/

            Object oPerf;
            FileObject localFo = getAttributeCache().getDelegate();
            String cachedAttrName = getAttributeCache().getAttributeName();

            if ((localFo != null) && !localFo.equals(this) && cachedAttrName.equals(attrName)) {
                if (localFo.isRoot() && (prefixattr != null)) {
                    try {
                        FileSystem foFs = localFo.getFileSystem();
                        if (!foFs.isReadOnly() || getMultiFileSystem().canHaveRootAttributeOnReadOnlyFS(prefixattr)) {
                            localFo = foFs.getRoot();
                            oPerf = getAttribute(localFo, prefixattr, ""); // NOI18N

                            if (oPerf != null) {
                                return devoidify(oPerf);
                            }
                        }
                    } catch (FileStateInvalidException fiex) {
                        //then continue
                    }
                }

                /** There is no chance to cache localFo.getPath(), because every
                 *  rename up to it in hierarchy makes this cache invalid.
                 */
                oPerf = getAttribute(localFo, attrName, localFo.getPath());

                if (oPerf != null) {
                    return devoidify(oPerf);
                }
            }
        }


The line (792)

    String cachedAttrName = getAttributeCache().getAttributeName();

returns a valid (pre-read) name ("position") and the first if-statement is true. 

The line (814):

    oPerf = getAttribute(localFo, attrName, localFo.getPath());

returns the wrong value (the default from the layer.xml, not the changed attribute value)


From my feeling it's an P1 in case of the unexpected runtime results.

As developer I've found two workarounds: 

  Read a different attribute before 
or 
  cast the FileObject to FileChangeListener and call fileRenamed (null) 
  to delete the internal cache via updateAll/mfo.freeAttribCache();

but this is only a well known implementation hack and doesn't have an effect to the existing code in the platform.

best regards,
  josh.