On Sat, Aug 10, 2013 at 10:53 PM, Glenn Fowler <[email protected]> wrote: > > 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
I know... "..." works... but looking at my parents Windows and OS X machine I think every other sane/insane naming scheme is already in use by Windows applications. And the users... the users... make it worse. You'd have files like "foobar[2][email protected]" and the users turn that into "foobar[2][email protected] -->{fuer morgen, geht um $$$$!!}<--" (short... they may put real-world language (comments, notes, curses etc.) with ASCII art into filenames... including the use of '&', '*', '^', '|' etc.). ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) [email protected] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
