Bug 42412

marked with core-promod 

A little update: I think I may be able to do a decent impl of external
source roots without any file attrs or other persistent information,
so this is not really P1 (probably not blocking project system work).

MasterFileSystem will store attributes in one shared .nbattrs file
because there is expected that there should be rarely necessary to
store attributes relateted to sources with current buildsystem and
there is planned to eliminate it at all. 

Location:  ${netbeans.user}/var/cache/attribs/.nbattrs. 
Format: see next attachment.

There is planned to keep backard compatibility.


Prelimanary implemented but not used yet.
/cvs/openide/masterfs/src/org/netbeans/modules/masterfs/ExLocalFileSystem.java,v
 <--  ExLocalFileSystem.java
initial revision: 1.1

/cvs/openide/masterfs/src/org/netbeans/modules/masterfs/SpecialDelegates.java,v
 <--  SpecialDelegates.java
new revision: 1.5; previous revision: 1.4

/cvs/openide/masterfs/src/org/netbeans/modules/masterfs/providers/Attributes.java,v
 <--  Attributes.java
initial revision: 1.1

Created attachment 14809 [details]
example of .nbattrs

Jarda asked me to go with this issue through DevRev.

If there are no objections will be commited and will be mentioned
appropriately in arch document for masterfs.

Performance-wise, wouldn't some flat-format (ideally fixed/known record length) perform 
better?  I can imagine a solution which (assuming that there are not really many types of 
attributes used), and possibly a limited (but more than needed) number of attrs per file, 
and you could do the following:

Each known attribute type will have its own filename.  Filenames for attribute types will be 
a fixed length (0 padded hash of attribute text?).

Master index file:
[path-to-file] [attrFileName 1] [offset] [length] [attrFileName 2] [offset] [length] [...padding 
to record length]

Per-attribute files:
[0-nnn] Attribute name (filename hash should match)
[path-to-file] [attribute data]
[path-to-file] [attribute data]


I don't know, maybe this is overkill, if attributes will be rarely used and we will load/parse 
the xml on startup.

Probably overkill; I would expect few total attributes to be in use.

One of the usages of .nbattrs is JavaConnectionSupport. Dusan and
Honza should add their comments if it is really going to die with MDR
or not.

I hope that attrs marking files treated as text will be obsolete after
Yarda's changes to DefaultDataObject. I am not sure about Ant vs
general XML but guess that Jesse solved it.

Mark as Servlet/RMI will be useless with MDR too so they will not use
this attrs too. Another use in webapps was to store parts of URIs +
URL parameters for execution of single JSP/servlet.

BTW, we should preserve the capability to read attributes from the
current location of .nbattrs to allow migration of old sources. We
have a couple FS attributes where in previous releases we stored data
that we want to import to the new projects-based system. Is this planned?

JavaConnectionSupport over .nbattrs will be definitely replaced with MDR.

But java module uses .nbattrs also to store encoding of file content
if other than the default one is used.

Re. encoding of file content: see issue 42638. Once it is in trunk the
JavaDO should use it instead.

Still every folder expanded in explorer will try to read 'sort mode'
property and we will check if the .nbattrs exists in original folder.
Maybe not so important as the primary view should be logical view but
it would be better to avoid this.

Let's kill sort mode for non-SFS DataFolder's. It's insane. I think we
already turned off D&D reordering of random folders, thankfully.

Re. Ant module - has not used file attrs for a long time.

Re. URLs for running a single servlet, etc. - any such use cases
should be handled sanely by a project, and not using file attributes.

RE. sort mode: yes, D&D on folders was disabled - it make sense only
on SystemFS. As for the SortMode I agree - it should be deleted and if
needed there should be global SortMode setting used by all folders. If
I do not hear objections I will file issue for myself to remove it. 

FYI: issue 43189 - "remove SortMode from non-SFS DataFolder's"

I filled issue 43238 for webapps to not store query strings in file
attributes.

Re ConnectionSupport - should we deprecate it once we will have MDR?

Radek,  is this done?

Done