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.
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:
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
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
new revision: 1.72; previous revision: 1.71
new revision: 1.2; previous revision: 1.1
new revision: 1.4; previous revision: 1.3
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