On Thu, 22 Aug 2013 17:13:48 +0200 Irek Szczesniak wrote:
> On Thu, Aug 22, 2013 at 5:05 PM, Glenn Fowler <[email protected]> wrote:
> >
> > On Thu, 22 Aug 2013 11:54:10 +0200 Cedric Blancher wrote:
> >> Glenn, when is the next alpha/beta due for AST and for UWIN? Is there
> >> a roadmap what you are planning long-term for AST and UWIN?
> >
> > I've been working on an ast-open pre-alpha that will (hopefully) clean up
> > pseudo devs, O_XATTR extended attributes, and *at() usage across ast by
> > these pseudo paths
> >
> > /dev/<IP-PROTOCOL>/<HOST>/<PORT>
> > /dev/fd/<FD>[/...]
> > /proc/<PID>/fd/<FD>[/...]
> > /dev/file/<FLAG>[,<FLAG>...]:/<ABSOLUTE-PATH>
> > /dev/file/<FLAG>[,<FLAG>...]:<RELATIVE-PATH>
> > /dev/@/:/<ABSOLUTE-PATH>[/@/<RELATIVE-ATTRIBUTE-PATH>]
> > /dev/@/:<RELATIVE-PATH>[/@/<RELATIVE-ATTRIBUTE-PATH>]
> <rant>
> How often must people REPEAT that this attempt is USELESS? O_XATTR
> doesn't have a name binding and cannot be assigned be without breaking
> something else, usually catastrophically. This is one of the
> experiments which just steal time, for example which could better be
> invested to FIX the utterly broken job control in ksh93. Recall my
> rant about the jobs variable being an utter misdesign because it is
> accessed in unsafe manner from both signal handlers and normal code?
> That code now breaks with clang -O2 or better, for good reasons
> (again, ISO C violation).
> FYI Merk Biostem uses files called @, @foo, foo@ and even brackets, so
> /dev/@/: won't work. Almost every other valid ASCII character except
> '\0' is allowed on Windows, rendering this attempt moot too.
> </rant>
dgk handles ksh issues and he is doing that as I type
like I said its pre-alpha
I'm aware of O_XATTR not residing the the namespace
that's the reason why code dealing with them is so crappy and fragile
the
/dev/@/:/<ABSOLUTE-PATH>
/dev/@/:<RELATIVE-PATH>
forms handle the -@ stuff, the second @ is experimental
since its experimental there may be some problems
in this case the existence of a non-O_XATTR file "@"
I'm aware of that possibility and don't have a solution to that working *yet*
but it is certainly possible to detect and differentiate a real "@" from an
attribute file
what that differentiation looks like I don't know *yet*
that would be the next part of the experiment
btw windows is not the best reference because although it allows any ASCII char,
some of them have special windows-only meaning
< > : " \ | have special meaning
: is used for windows equivalent to O_XATTR
/ and \ can be path separators
aux, nul, prn, com[0-9] are special file names in *any* directory
not to mention case ignorance
_______________________________________________
ast-developers mailing list
[email protected]
http://lists.research.att.com/mailman/listinfo/ast-developers
