Hi Fons, Ok, Andy will have to reply as to how or if he can support relative paths and/or "~/". Ah, yes, the "echo ~/myfile.root" must be done on the client side. That already makes things a bit easier as then (for example) the actual file being opened by the server would be: root://host:port//users/elmer/myfile.root or better, the server would get just: /users/elmer/myfile.root so such a thing could be supported by a server side configuration directive such as: xrootd.export /users which would allow access to all user areas. (Assuming TXNetFile/TXUrl doesn't balk at the "~" before it gets interpreted.) Pete On Wed, Aug 18, 2004 at 03:01:14PM +0200, Fons Rademakers wrote: > Hi Pete, > > the old rootd after the user has been authenticated is using the users > home directory as starting point for relative paths. So for the case: > > root://host:port/myfile.root > > and for > > root://host:port/~/myfile.root > > the same file pw_dir/myfile.root will be opened. In the second case the > command "echo ~/myfile.root" is used to return pw_dir/myfile.root. > > Cheers, Fons. > > > On Wed, 2004-08-18 at 14:39, Peter Elmer wrote: > > On Wed, Aug 18, 2004 at 02:25:49PM +0200, Fons Rademakers wrote: > > > Yes, I get an error message from TXUrl. Gerri can you maybe check this > > > and fix it so that localhost works again in the rootd url? > > > > > > Other question, how do I start xrootd so that is assumes relative paths > > > to start in the users home directory? Now default is /tmp. > > > > Which user? The one which started xrootd or the one accessing files? > > > > xrootd behaves differently that rootd in this respect. It doesn't assume > > that paths start in /tmp by default, it only allows access to /tmp by default. > > I've recently started to add some example configurations to describe some > > things: > > > > http://xrootd.slac.stanford.edu/examples/ > > > > but the short answer is that you can export other area (e.g. like /data) with > > either a line in the config file: > > > > xrootd.export /data > > > > or by starting xrootd as: > > > > xrootd /data > > > > I don't think it takes a "*" (obviously very insecure). > > > > There is a separate option "oss.localroot" which allows for a _global_ > > server side prefix to all paths, i.e. a file at /mnt/temp/path/myfile.root > > with: > > > > oss.localroot /mnt/temp > > > > will be accessed as > > > > root://host:port//path/myfile.root > > > > I'm not actually surt how it will behave for relative paths: > > > > root://host:port/myfile.root * > > > > or for > > > > root://host:port/~elmer/myfile.root > > root://host:port/~/myfile.root * > > > > This is what you are asking about, is that correct? Could you remind me > > exactly what is done by rootd in the two cases marked with an "*"? (i.e. > > relative path WRT what and "~" means which user?) > > > > Pete > > > > > > > > > On Wed, 2004-08-18 at 11:24, Peter Elmer wrote: > > > > Hi Fons, > > > > > > > > On Tue, Aug 17, 2004 at 12:48:43PM +0200, Fons Rademakers wrote: > > > > > the rule in TFile::Open for opening via rootd currently is: > > > > > > > > > > "If the url points to the localhost and the file will be opened in > > > > > readonly mode and the current user has read access or the specified > > > > > user is equal to the current user then open local TFile." > > > > > > > > > > This feature is specially important for PROOF where we access files > > > > > always via rootd urls (so any worker can access any file) but where the > > > > > packetizer optimizes the work so that the workers mostly will get local > > > > > files. Using the above feature these local files will be opened directly > > > > > as TFile's and won't go through rootd. To force a local file to be > > > > > opened via rootd specify as host "localhost". If TXUrl this also > > > > > supports then we will have the same behavior. If this "localhost" > > > > > feature is supported by netx/xrootd then we can always use that as > > > > > "backdoor" to test xrootd on the same machine as where the client runs. > > > > > > > > Yes, the "localhost" option was in fact what Alvise and Fabrizio were > > > > using themselves for this purpose. I've still not succeeded in building > > > > the HEAD, but is the issue you are seeing related to the "in or out domain" > > > > checks? That is what I was seeing with the last XTNetFile version before > > > > they began the migration to TXNetFile. ------------------------------------------------------------------------- Peter Elmer E-mail: [log in to unmask] Phone: +41 (22) 767-4644 Address: CERN Division PPE, Bat. 32 2C-14, CH-1211 Geneva 23, Switzerland -------------------------------------------------------------------------