From the users' point of view, practically speaking, another advantage for not writing these back is that a user could start up processes that create these sockets/pipes from multiple locations without disruption.
If you have sockets/named pipes written back to the server, can they really be used from multiple clients? The idea of "distributed sockets/named pipes" as Tom Keiser pointed out would require implementation in the file server, i.e. socket/pipe data to be sent accross the file server (wouldn't it?). It also seems that this kind of solution would require some new type of knowledge on the part of the software that reads/writes to/from the sockets/pipes. This seems a bit more of a stretch in terms of purpose/goals of AFS. On Thursday 16 September 2010 10:32, Derrick Brashear wrote: > The point of not writing back is that it can be done today without protocol > change. No issue of what unsuspecting clients see, because what they see is > ... nothing. > > On Sep 16, 2010, at 3:53 PM, Andrew Deason <[email protected]> wrote: > > On Thu, 16 Sep 2010 07:53:59 -0400 > > > > chas williams - CONTRACTOR <[email protected]> wrote: > >> On Thu, 16 Sep 2010 09:58:22 +0200 > >> > >> Derrick Brashear <[email protected]> wrote: > >>> 2) if created locally they would cover a later file of the same name > >>> if one is created > >> > >> how about a new 'file type' that is 'special' just like mounts. > >> however, they would only have a local (to the client host) > >> meaning. old clients would see 'files' (with a strange prefix i > >> guess) and new clients would be able to handle these things as special > >> devices (named pipes and the like). > > > > Old clients could write stuff to that file, though, which is also thus > > hidden from new clients. Unless you add knowledge about the special > > prefix or whatever to the fileserver, prohibiting such. > > > > We can't create an actual new file type? (as in, an > > AFSFetchStatus.FileType type) > > > > -- > > Andrew Deason > > [email protected] > > > > _______________________________________________ > > OpenAFS-devel mailing list > > [email protected] > > https://lists.openafs.org/mailman/listinfo/openafs-devel > > _______________________________________________ > OpenAFS-devel mailing list > [email protected] > https://lists.openafs.org/mailman/listinfo/openafs-devel _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
