Hi Fabrizio, There is nothing in the protocol that prevents this. Since opaque information is opaque and is always passed as part of a filename, xrootd simply forwards that information without interpretation. They could be the same or different, depends on the application. Andy On Thu, 28 Apr 2005, Fabrizio Furano wrote: > Hi, > > uhm. I see and don't see. Will it have two opaque parameters or the > same parameter appended to each filename? > > Fabrizio > > Andy Hanushevsky wrote: > > Hi Fabrizio, > > > > I think we all agree on that. The only "nit" is that rename will have > > two opaque parameters that someone will need to make sense of. > > > > Andy > > > > ----- Original Message ----- From: "Fabrizio Furano" > > <[log in to unmask]> > > To: "Andrew Hanushevsky" <[log in to unmask]> > > Cc: "Andreas Joachim Peters" <[log in to unmask]>; "Derek Feichtinger" > > <[log in to unmask]>; "Fons Rademakers" > > <[log in to unmask]>; "xrootd mailing list" > > <[log in to unmask]> > > Sent: Wednesday, April 27, 2005 7:24 AM > > Subject: Re: olbd fails to learn when a file disappears from a leaf > > node, but another copy still exists > > > > > >> Hi, > >> > >> I argue from this that the opaque info passed e.g. through xrdcp must > >> be passed for any request containing a filename, like Stat or Dirlist. > >> Am I right? > >> > >> Fabrizio > >> > >> Andrew Hanushevsky wrote: > >> > >>> Hi Andreas, > >>> > >>> OK, so it would appear that we will need to extract out the information > >>> after the "?" and pass that as a separate parameter. I do that, > >>> instead of > >>> passing the complete url, so as to not re-implement searching for the > >>> opaque information in every function. The called function, hoewver, is > >>> responsible for making sense of the opaque information. > >>> > >>> That does mean changing most file system calls to include the opaque > >>> parameter. That also solves the olbd issue in a unified way. > >>> > >>> Do we all agree to go that route? > >>> > >>> Andy > >>> > >>> On Tue, 26 Apr 2005, Andreas Joachim Peters wrote: > >>> > >>> > >>>> As it is, it is absolutely fine for me. I would prefer, that the > >>>> complete > >>>> URL is always passed to any function and the function has to extract > >>>> the part > >>>> it needs. But as it is, it works perfectly for us. > >>>> > >>>> I use the following syntax: > >>>> > >>>> root://server.domain:port/<lfn>?&authz=<authorization block> > >>>> > >>>> Because even for a stat command it can be useful, that you can specify > >>>> some environment variable like the stagepool the file is on. > >>>> > >>>> Cheers Andreas. > >>>> > >>>> > >> >