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...
----
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
