Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 42412 - [2004-05-14] Store file attributes privately in the user dir
[2004-05-14] Store file attributes privately in the user dir
Product: platform
Classification: Unclassified
Component: Filesystems
All All
: P2 (vote)
: 4.x
Assigned To: rmatous
Depends on:
Blocks: 42259
  Show dependency treegraph
Reported: 2004-04-23 18:32 UTC by Jesse Glick
Modified: 2008-12-22 23:00 UTC (History)
7 users (show)

See Also:

example of .nbattrs (392 bytes, text/plain)
2004-05-11 13:45 UTC, rmatous

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2004-04-23 18:32:36 UTC
For remaining usages of file attributes, we
probably do not want to clutter the user's source
tree with .nbattrs files. They should be stored
privately in one database in the user directory.
The DB can be purged sometimes of references to
files which no longer exist.

masterfs should be able to do this.

I would very much like such a change in order to
properly support external source roots for the
project system. If it isn't done at the
filesystems layer, I would just have to do the
same thing in the projectapi module anyway. I am
willing to work on an impl.
Comment 1 _ ttran 2004-04-23 22:31:31 UTC
marked with core-promod 
Comment 2 Jesse Glick 2004-04-23 22:54:18 UTC
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).
Comment 3 rmatous 2004-05-11 13:43:47 UTC
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.
initial revision: 1.1

new revision: 1.5; previous revision: 1.4

initial revision: 1.1
Comment 4 rmatous 2004-05-11 13:45:22 UTC
Created attachment 14809 [details]
example of .nbattrs
Comment 5 rmatous 2004-05-11 13:53:26 UTC
Jarda asked me to go with this issue through DevRev.
Comment 6 rmatous 2004-05-11 14:07:43 UTC
If there are no objections will be commited and will be mentioned
appropriately in arch document for masterfs.
Comment 7 _ tboudreau 2004-05-11 16:30:48 UTC
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.
Comment 8 Jesse Glick 2004-05-11 16:33:45 UTC
Probably overkill; I would expect few total attributes to be in use.
Comment 9 _ rkubacki 2004-05-12 13:29:34 UTC
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.
Comment 10 Petr Jiricka 2004-05-12 13:58:23 UTC
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?
Comment 11 Jan Pokorsky 2004-05-12 14:28:22 UTC
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.
Comment 12 David Konecny 2004-05-12 14:47:56 UTC
Re. encoding of file content: see issue 42638. Once it is in trunk the
JavaDO should use it instead.
Comment 13 _ rkubacki 2004-05-12 16:16:41 UTC
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.
Comment 14 Jesse Glick 2004-05-12 16:47:39 UTC
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.
Comment 15 David Konecny 2004-05-12 17:06:31 UTC
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. 
Comment 16 David Konecny 2004-05-13 09:16:32 UTC
FYI: issue 43189 - "remove SortMode from non-SFS DataFolder's"
Comment 17 _ rkubacki 2004-05-13 22:28:39 UTC
I filled issue 43238 for webapps to not store query strings in file

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

Comment 18 _ ttran 2004-06-06 00:06:11 UTC
Radek,  is this done?
Comment 19 rmatous 2004-06-07 12:07:13 UTC

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo