 |
 |
Hi Fabrizio, Yes, I am confused as well. OK, I see your dilemma. The problem is that from the olb view, there are no directories. Files names are just arbitraty strings. So asking questions via the olb about directories is sort of meaningless. So, I will propose another solution: What if the xrootd returns the (new) error kXR_NotFile when you try to open a directory (recall that xrootd does not allow you to open directories). Then you will know, with about 99.9% accuracy that this is a directory (it could also be somethig else but very unlikely) and use directory target semantics. Would this be sufficient? Andy P.S. This also would fix the problem that xrootd really does allow you to open directories; though you can't realy do anything rationale after that. ----- Original Message ----- From: "Fabrizio Furano" <[log in to unmask]> To: "Andrew Hanushevsky" <[log in to unmask]> Cc: "Wilko Kroeger" <[log in to unmask]>; <[log in to unmask]> Sent: Thursday, November 18, 2004 5:06 AM Subject: Re: xrdcp and redirector > Hi all, > > i feel a bit of confusion. I never changed the mechanism. > > From my point of view, xrdcp was meant with a "cp-like" semantic. > > Hence, when given an xrootd destination string, it has to know if that > string is a directory or not. And this means that it has to stat that > string. > > If it's a directory, then the source filename (for any source filename > coming from the recursive procesing of the source string) is appended to > this string, otherwise the string is treated as a full destination > path/file. > > In parallel, there is the mkdir mechanism, which (more or less > blindly) creates the intermediate path for each destination. > > So, at a first sight, those three steps imply that the meaning of the > destination string has to be slightly different. Or am I wrong? > > Or we could make the assumption that, if step 1 fails, it's failing > because the dest string is a directory not to be overwritten with a > file. Do you agree on this? > > Anyway, I'll give a look at the code to see if this proposed policy > conflicts or not with the recursive copy mechanism. Maybe no. > > Fabrizio > > > > Andrew Hanushevsky wrote: > > Absolutely correct. I thought we went through this: xrdcp should *not* do a > > stat prior to opening the file. Fabrizio, I thought you said that this was > > changed. So, this is very confusing now. > > > > Andy > > > > ----- Original Message ----- > > From: "Wilko Kroeger" <[log in to unmask]> > > To: <[log in to unmask]> > > Sent: Wednesday, November 17, 2004 7:52 AM > > Subject: xrdcp and redirector > > > > > > > >>Hello Fabrizio > >> > >>I tried xrdcp from the head together with a redirector. > >>The setup is simple: one redirector and one data server and > >>I try to copy a local file to an xrootd data server. > >>Unfortunately, xrdcp failed so far claiming that no data server > >>is available. > >>I have a question regarding the steps within xrdcp. Looking > >>through the logs it looks like that xrdcp first stats the file > >>and directory the files should go to and then if the dirs don't > >>exist it tries to create them. However all these steps fail because > >>the redirector doesn't return a data server. > >> > >>As far as I understand a redirector returns a valid data server > >>if it receives a request to write a file, and therefore writing to > >>xrootd should follow the steps below. Is this true and is this > >>implemented in xrdcp ? > >> > >>1) open/write the file to xrootd (the redirector should return a valid > >> data server) > >>2) if 1) fails do the stat and mkdir on the data server obtained in step > >> 1). > >>3) repeat step 1). > >> > >> > >>Cheers, > >> Wilko > >> > >> > >> > >> >