Joseph wrote:
> In general, I would suggest it might be appropriate to store
> a small amount of data as an ADS. For example, storing the
> subversion properties as an ADS sounds like it would be a
> sensible use (they might even stay MFT resident in which
> case you wouldn't incure a allocatition-block-size hit in
> disk space for a 12 byte string.)
I agree. And MFT-resident is what I was getting at when I mentioned locality. I guess each filesystem has a different amount of space in the i-node for an attribute map, or the first bytes anyway. NTFS: 12 bytes (sounds familiar from Helen Custer's book); BFS: 760 bytes (Practical Filesystem Design); HPFS: 0 (none of attributes stored with inode), with 64k upper bound. I don't know anything about Mac -- seems like I've been saying that for too many years now. But from what I've heard, the OS X team was the BFS team. Wikipedia's HFS+ entry ("6. Attributes File" section) seems to imply the answer is 0 (no attrs stored with inode). This page mentions a few interesting HFS+/xattr-API attribute naming and file naming rules.
Joseph wrote:
> Storing the textbase does not [make sense]-- both because of the large amount
> of space being 'hidden' and because you have no way to prevent
> the user from deleting it.
Again, sounds reasonable.
If the svn project were to follow such a tack, the .svn/props/ and .svn/prop-base/ folders could go away, which, among other benefits such as fixing OS metadata and search facilities, could have performance implications on certain platforms worth getting excited about.
David
----- Original Message -----
From: "Joseph Galbraith" <galb@vandyke.com>
To: "David Rauschenbach" <davidr@goodserver.com>
Cc: "Michael Sinz" <Michael.Sinz@sinz.org>; <dev@subversion.tigris.org>
Sent: Monday, February 06, 2006 1:01 PM
Subject: Re: using NTFS ADS, HFS+ ResourceForks or other file system metadata facility instead of a .svn directory
> David Rauschenbach wrote:
>> Hi Michael,
>>
>> Michael wrote:
>>> I would much rather try
>>> sticking to the goal of Subversion being a revision management
>>> system and that the files are "sacred" and should not be corrupted
>>> or changed due to the use of Subversion. (I should get back what
>>> I put in)
>
> Just to kind of throw gasoline on the fire :-)
>
> NTFS doesn't allow an unlimited number of ADS per file. I don't
> recall what the limit is, but it was surprisingly low (at least
> I recall being surprised when I heard it-- several thousand but
> not 10's of thousands I think.)
>
> I'm pretty sure that ACLs are not really stored as a named data
> stream... so you couldn't overwrite the ACL with creative use
> of CreateFile("myfile:$ACL") or some such. Likewise, create
> time, change time, modified time, last access, and the file
> attributes (including archive bit) are also not stored as
> an ADS.
>
> In terms of 'sacred' data... I don't believe that it would
> have an impact. If subversions stored per-file meta data
> in a ADS call myfile.txt:.svn, you'd have the same chances
> of colliding with a real data stream as you do with today's
> .svn directory for meta-data.
>
> However, it was only as of Windows 2003 that microsoft
> finally introduced a real way to enumerate alternate
> data streams. (Previous to that you had to use tricks
> with the backup APIs and parsing the backup data.)
>
> As a result, most tools (including exploder) are not
> aware of streams. If you want to see and admin turn
> purple, mutter words like "root-kit", "malware", and
> other creative swear-words, take half his disk space
> and make it disappear from the view of all his available
> tools... it's gone, but he can't figure out where.
> Unfortunately, that is the state-of-ads as it stands
> today.
>
> In general, I would suggest it might be appropriate to store
> a small amount of data as an ADS. For example, storing the
> subversion properties as an ADS sounds like it would be a
> sensible use (they might even stay MFT resident in which
> case you wouldn't incure a allocatition-block-size hit in
> disk space for a 12 byte string.)
>
> Storing the textbase does not-- both because of the large amount
> of space being 'hidden' and because you have no way to prevent
> the user from deleting it.
>
> Thanks,
>
> Joseph
>
Received on Mon Feb 6 20:30:45 2006