On Sat, 10 Aug 2013 22:27:23 +0200 Roland Mainz wrote:
> On Sat, Aug 10, 2013 at 3:36 PM, Glenn Fowler <[email protected]> wrote:
> > On Sat, 10 Aug 2013 04:55:17 +0200 Roland Mainz wrote:
> >> Attached (as "astksh20130807_solaris_cd_fixes001.diff.txt") is a patch
> >> (technically the 4th or 5th attempt to submit this patch... ;-( ) to
> >> get cd(1) fixed on platforms like Solaris/AIX/etc.
> >
> >> * Issues fixed:
> >> - cd -@ shoud use correct error handling
> >> - |rehash()| is a libc function on some systems and causes issues on
> >> such platforms... the patch renames |rehash()| to
> >> |rehash_relpathbindings()|
> >> - Don't use |fstat()| to test for directory if we have |O_DIRECTORY|.
> >> Fixes Solaris's samfs
> >> - src/cmd/ksh93/include/shell.h - add a comment for |shp->pwdfd| to
> >> explain which functions should be used to obtain this file descriptor
> >
> > it still has not been explained why special fs treatment like this
> > goes into ksh and not src/lib/libast/something
> > is this really something *only* ksh will trip over
> > or is it a more general problem that should be handled in a more general way
> I'm not sure... for now I've implemented cd -@ based the
> furious/frustrated stories of Sun's PIT (=PreIntegration Testing)
> people in Ireland who had no way to look at the XATTR files in any
> usefull way.
> For now I would keep it at this level (e.g. cd -@, ls -@, find -xattr
> and "pax" support) until we have more feedback from the users what
> they intend to do with it. And we only get that if $ cd -@ myfile #
> works properly...
> > if any other ast command/library/user could trip up over the same rigmarole
> > then it belongs in a common place
> Agreed... but please please not this time. Not for the next couple of alphas.
> The concept of |O_XATTR| is fairly new and is making it only slowly
> into the various OSes and filesystems. |O_XATTR| is a solution of
> combining&&unifying ([1]) the concepts of the so-called "resource
> forks" on Apple (pre-OSX), Amiga's INFO files, WindowsNT's "Alternate
> Data Streams" and almost all other file metadata concepts one API.
> The basic idea is: You can have metadata of unlimited size (not
> limited-sized string APIs), store it "near" the file object it belongs
> to and they are removed when the file gets removed (anyone recalling
> AmigaOS... if you remove files from the shell you could've left-over
> INFO files).
> [1]=For example Apple OS (pre-OSX and OSX) doesn't have traditional
> filesystem APIs to access resource forks. However a NFSv4 filesystem
> client module will translate all the custom resource fork APIs into
> |O_XATTR| calls to the NFSv4 server and the server will understand
> what's meant.
> The same applies to "Alternate Data Streams" ... Windows uses custom
> APIs for this but an smbfs client translates these calls again into
> |O_XATTR| file accesses...
> Note that this means you should not try to put that into libast or
> UWIN and emulate |O_XATTR| ... that's even more painfull than the work
> for ACLs.
> The good side is that |O_XATTR| slowly filtering into the OSes because
> both smbfs and NFSv4 need it and the existing limited-size string APIs
> are horrible...
> > and it still hasn't be explained how these fs extensions ignore
> > fs semantics and paradigms that until this point have been working fine
> > since 1970
> Grumpf... the issue is that there is no POSIX-conforming way to do it
> unless you restrict the namespace available for filenames. The other
> issue is that the XATTR files should be removed with the "parent file
> object" causing even more semantic pain. Finally Sun's enginners
> decided to avoid the issue completely for now and just don't decide on
> a naming scheme at all.
> > in particular, just how many commands in the wild need -@ args now?
> > is this an opportunity to do something like
> > /dev/rigmarole@.../...
> > and have it magically work for all ast commands/libs/plugins
> Not really... I already thought about /dev/xattr@ and decided against
> it because it raises more dead issues from the grave than it solves.
> Right now the |O_XATTR| directories are "flat", e.g. no subdirectories
> are allowed in the Sun _implementation_... but the code in NFSv4
> explicitly allows subdirs... which makes it hard to come-up with a
> naming scheme for the same reason Sun didn't come-up with a naming
> scheme to represent such files in the filesystem itself (and I don't
> want to start with { \t, \v etc. } ... Sun's engineers tried that as
> experiment and promptly broke ar(1) with that).
> Thinking about it... IMO the best thing is really really to just fix
> cd(1) and see what users do with it...
thanks for the background
we did something similar with version files in 3d fs
we encroached on the namespace by taking "..."
if you want the latest version of file foo name it
"foo"
if you want to see all versions of foo and other resources name it
"foo/..."
if you want to see version bar of file foo
"foo/.../bar"
we didn't use it much beyond proof of concept
so e.g. readdir() did not return "..." files
_______________________________________________
ast-developers mailing list
[email protected]
http://lists.research.att.com/mailman/listinfo/ast-developers
