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.
Currently in var/cache/attributes/.nbattrs. Should not be in var/cache/ - it is not a cache of anything, it is first-class data (in general). Not sure if var/ is even right, but at least var/attributes/.nbattrs (or just var/attributes.xml) would be an improvement.
OK. There was intentionally involved apireviewers to provide comments or recommendation about format and location in original issue #42412.
Jesse is right, the file should not be .nbattrs, but something more reasonable like attributes.xml. As concern the comment about location, this is probably valid as well.
/cvs/openide/masterfs/src/org/netbeans/modules/masterfs/providers/Attributes.java new revision: 1.2; previous revision: 1.1 New location: var/attributes/.nbattrs.
And I thought that both Jesse and me suggested to use something different than filename starting with a dot!?
AFAIK the first comment written by Jesse contatins two choices: - var/attributes/.nbattrs - var/attributes.xml I accepted the first one (the reason is that I reuse DefaultAttributes that use .nbattrs as default and there isn't any common way how to change it only for MasterFileSystem attributes). AFAIK till now all attributes were named just .nbattrs - even those that were stored in userdir. If there is any *crucial* reason (maybe ARCH blocker) why the second one is better then please mention it in this issue in more detail and reopen.
The reason why we used .nbattrs was that we wanted to hide them as metadata from users of regular directories. This is not needed anymore as they are hidden by default in var/attributes directory. So this is a reason why we do not need them. As now the metadata are moved to their own directory, they are no longer second class citizen in their directory, but are an important file in var/attributes directory. The whole var directory should be hidden (and it is under .netbeans/dev) but data inside should be discoverable. That is the reason why we should not use dot prefix. I'll leave on others to judge and reopen and reprioritize the bug.
Agree with Yarda but don't consider it a priority relative to other stuff.
I'm reopening as I'm already the third person thinking attributes.xml is better name and .nbattrs should not be used (exactly for the reason Yarda mentioned). Talked about this on DevRev too.
Should be possible to deprecate all the .nbattrs-based code in o.o.filesystems, since no one should now be using it anyway (except XMLFileSystem? but not in quite the same way; and anyway not used normally because of layer caching!); copy the impl to the masterfs module and modify it to better match its new usage. Besides choosing a better name for the file, I suggested that a different DTD and syntax be used since the existing attributes DTD is not designed for this kind of usage; it is intended for representing files only in the same dir. The syntax <fileobject name="|space|src|ant|src|main|org|apache|tools|ant|AntClassLoader.java"> is clearly a hack and since we define and control this format entirely we should make it look more reasonable (IMHO). Again, I don't consider this a real priority when there are other things to do, but maybe others care more.
XMLFs doesn't use DefaultAttributes at all. MAsterFS delegates either on LocalFs or VCSFs where both are AbstractFileSystems that must somehow implement Attr interface. You are right that VCSFs is just plugin in MasterFS and then MasterFS can overtake this functionality (but be aware that VCSFs relies that its impl. of Attr inteface will be called - maybe can be ommited ?) but LocalFs is part of API, can be used as standalone FS and is used as part of SystemFileSystem as its writable layer (and creates .nbattrs files). There is naturally possible to use deprecated DefaultAttributes for LocalFS anymore or can be reimplemented. Definitely I thought that attributes on MasterFS shouldn't be used at all and that I must ensure just backward compatibility and not fire IOException from setAttributes (which is completely OK according to filesystem API and I expected to do it in future). If so then I don't understand why you decreased priority. If not then I didn't get it and please increase priority again.
"I thought that attributes on MasterFS shouldn't be used at all" - umm... I'm not sure that's true. Probably still TBD. There may be occasional uses of user-level file attributes that we want to keep; e.g. I was considered using (unsharable) file attributes to mark external source roots for projects persistently, though the current code does this only transiently. Of course in such cases it is possible to persist this kind of information using custom cache storage; using file attributes is just the most convenient way.
Thanks guys for support with the name of the file. Because this is an API it needs to be fixed before release otherwise we just get into compatibility troubles. Personally I wonder what it so complicated on changing the name of file? If a request for change of the content of the file is hard to implement, I can live without it, but change the name.
OK if you have use cases and enough of votes then I'm ready to fix it. I plan to add new public constructor into DefaultAttributes that will take name of file (In this case attributes.xml). But if there is strong requirement to change format then I need to know how. Needless to say that I would welcome if I could reuse DefaultAttributes.
/cvs/openide/src/org/openide/filesystems/DefaultAttributes.java,v <-- DefaultAttributes.java new revision: 1.72; previous revision: 1.71 /cvs/openide/masterfs/src/org/netbeans/modules/masterfs/ExLocalFileSystem.java,v <-- ExLocalFileSystem.java new revision: 1.2; previous revision: 1.1 /cvs/openide/masterfs/src/org/netbeans/modules/masterfs/providers/Attributes.java,v <-- Attributes.java new revision: 1.4; previous revision: 1.3 /cvs/openide/openide-spec-vers.properties,v <-- openide-spec-vers.properties new revision: 1.145; previous revision: 1.144 /cvs/openide/api/doc/changes/apichanges.xml,v <-- apichanges.xml new revision: 1.201; previous revision: 1.200