--LTeJQqWS0MN7I/qa
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 28, 2005 at 03:28:58PM +0200, Reinoud Zandijk wrote:
> Hi,
>=20
> On Sun, Jun 26, 2005 at 07:07:14PM -0700, Jason Thorpe wrote:
> > >how about something-@ostype-@osrelease ?
> >=20
> > You really should be using subdirectories :-)

Uhm, I think you went of in an entirely different direction from what=20
Jason was talking about. Or else I was on the wrong page. :-)

I thought Jason was talking about how to structure directories so that a
magic symlink would get the right version for any OS. So you can tell
folks to add /afs/us/systems/bin to PATH, and have it be a symlink which
points to .../@ostype/@osrelease/something as opposed to it pointing to=20
=2E../something-@ostype-@osrelease/.

The difference would be are your directories:

NetBSD/2.0/foo
NetBSD/2.1/foo
NetBSD/3.0/foo
FreeBSD/5.2/foo

or

foo-NetBSD-2.0
foo-NetBSD-2.1
foo-NetBSD-3.0
foo-FreeBSD-5.2

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

This issue is different. Interesting and something we should talk about,=20
but different!

> These streamdir's are defined to accomodate named extended attributes nex=
t=20
> to UDFs normal extended attributes (like various extra timestamps as ther=
e=20
> are a.o. last backup time, valid-from, valid-until) or DVD's css info. So=
me=20
> are meant to be invisible, others are to be explicitly visible.
>=20
> 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.

I don't like the named stream format for ACLs. I could be persuaded, but I=
=20
think an API to access them would be better. If we have to do it to really=
=20
support UDF, so be it. But it's kinda gross. :-)

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

Reasonable. They are just add-on entities on top of the real underlying=20
directory entry.

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

chflags(1) may work for attributes, but not the resource fork. The=20
resource fork really is a separate file on top of the file.

> Luckily, in UDF named streams are not allowed to have subdirectries.
>=20
> Now i can see a couple of options on how to deal with it:
>=20
> option 1:
> 	ignore all, but preserve on operations like move etc. when not=20
> 	leaving the filingsystem otherwise discard them or raising an=20
> 	error. (simple, filingsystem internal)
>=20
> option 2:
> 	only allow these sub-files to be looked up when using open() but=20
> 	never list them. A naming scheme like "dirname/fname$attr" or=20
> 	"dirname/dirname$attr" could be used for this. (not intrusive but
> 	not consistent from user's perspective)

This option seems best. They aren't files, just different ways to access=20
parts of the file. Thus they should not show up in directory listings.

As Jason indicated, MacOS appends fixed strings.

> option 3:
> 	also list the files using the naming scheme but hide by=20
> 	default in `ls' unless otherwise instructed. (bit intrusive)
>=20
>=20
>=20
> Apart from these named streams, other extended attributes like the=20
> timestamps could be looked up by a new VOP primitive or also be presented=
=20
> as a named stream. UDF uses the Ecma-167 its based on: a 32 bit integer=
=20
> indicating wich times are defined for the file followed by a series of=20
> timestamps in increasing associated bitnumber.
>=20
> The VOP would allowing other filingsystems like FFS to support various=20
> extra times too without modifying struct stat. Extending/modifying struct=
=20
> stat is most likely not wanted though. Applications for such times could =
be=20
> backup managers searching of files that need to be backed up, filingsyste=
m=20
> purgers to purge old logfiles or even userdirs indicated to be removed=20
> after a time etc etc.

Use fcntl(2). We added a whole file system specific access part to it for=
=20
ACLs, and for what you're talking about it'd be the best way to go. Plus=20
it has the advantage that ACL operations can be performed on a file=20
descriptor. Adding an operation for backup time storage, as above, would=20
also make sense. And it also hits the abstraction point the same way as=20
ACLs.

Take care,

Bill

--LTeJQqWS0MN7I/qa
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFCwfLCWz+3JHUci9cRAkYkAJ4sv/ta6d5k3TnnhPxVgp0am1lF+wCdHZVp
pZaceCSIr5Yeslp5O3Uh9FE=
=hECr
-----END PGP SIGNATURE-----

--LTeJQqWS0MN7I/qa--