--X1bOJ3K7DJ5YkBrT
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hi,

On Sun, Jun 26, 2005 at 07:07:14PM -0700, Jason Thorpe wrote:
> >how about something-@ostype-@osrelease ?
> 
> You really should be using subdirectories :-)

yup...  though i have a similar naming problem as has HFS+. On UDF a file 
can have an associated streamdir with it basicly turning it into a 
composite of a file and a directory with named streams. Directories though 
can also have an associated streamdir with it. (!)

These streamdir's are defined to accomodate named extended attributes next 
to UDFs normal extended attributes (like various extra timestamps as there 
are a.o. last backup time, valid-from, valid-until) or DVD's css info. Some 
are meant to be invisible, others are to be explicitly visible.

Examples of use for the named streams :
	* Mac's resource fork
	* NT and/or Unix ACL's
	* indexing tables, derived data, preview images etc. etc.

If such a file or directory is moved/copied, all associated data is then 
copied with it though it still reads/writes like an ordinary file. Note 
that these files can not be hardlinked outside the file.

To fit those two concepts into the Unix filingsystem is a bit tricky since 
VFS doesn't understand this concept too well. HFS+ has some similar issues 
so maybe it would be good to think of a way of adressing such named streams 
and the file's associated attributes. The chflags(1) interface is the 
closest matching interface but far too limited.

Luckily, in UDF named streams are not allowed to have subdirectries.

Now i can see a couple of options on how to deal with it:

option 1:
	ignore all, but preserve on operations like move etc. when not 
	leaving the filingsystem otherwise discard them or raising an 
	error. (simple, filingsystem internal)

option 2:
	only allow these sub-files to be looked up when using open() but 
	never list them. A naming scheme like "dirname/fname$attr" or 
	"dirname/dirname$attr" could be used for this. (not intrusive but
	not consistent from user's perspective)

option 3:
	also list the files using the naming scheme but hide by 
	default in `ls' unless otherwise instructed. (bit intrusive)



Apart from these named streams, other extended attributes like the 
timestamps could be looked up by a new VOP primitive or also be presented 
as a named stream. UDF uses the Ecma-167 its based on: a 32 bit integer 
indicating wich times are defined for the file followed by a series of 
timestamps in increasing associated bitnumber.

The VOP would allowing other filingsystems like FFS to support various 
extra times too without modifying struct stat. Extending/modifying struct 
stat is most likely not wanted though. Applications for such times could be 
backup managers searching of files that need to be backed up, filingsystem 
purgers to purge old logfiles or even userdirs indicated to be removed 
after a time etc etc.

Thoughts ?
Reinoud

--X1bOJ3K7DJ5YkBrT
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)

iQEVAwUBQsFQk4KcNwBDyKpoAQLOHwf+PYy5mskKicMXiQrKFLePP3qIefPIPC/n
85daQsX/r8WhxkYw9PDuIxPtxWzh5cR/8uO1jBvOlXiRWy9sejeWzUzAMUCxnceE
2FP5H7+1n8ikmMzvq+qe3vCM9v3Sw/YUjVyGyLv9SYSvoAVQaCQuW4iX3n4JDGBk
RRzRm1/eswf7N+D/qUvBsN9OIeuRdiWZhgLcBeb5WnK2PSZ6UZooKHQu6FBfUbc6
bzmrWOldJ5flRRzZyWV+uT4M+Rg0xkb1pPyr4CBLaOO6bwAqkVAalHleNlOFrf5c
bFv4FDJddEAqYe6ICIccF46ez/HEI/msVgL2GomzcXoGqX+6nYbnJg==
=44bu
-----END PGP SIGNATURE-----

--X1bOJ3K7DJ5YkBrT--