[ee122] question about file names
dank at eecs.berkeley.edu
Wed Oct 24 15:47:39 PDT 2007
Without getting into a battle of words, here is the explanation:
Saving a file as /bar/foo means saving the file foo in the directory bar.
We don't want you guys to have to worry about making directories,
putting files in them etc., just being able to create a file in the
working directory is fine for the purposes of this project.
So your example request of /database/contents/ is saved as contents in
this directory, not contents in the subdirectory of database/
Clear now I hope. If not let me know...
Nescio Nomen wrote:
> Sorry, maybe I am just being dumb. Your claim is that the filename
> should be "contents", based on the following rule: "The new file name
> is the simple name of the URI, i.e., all the characters following the
> last '/'". Since the URI is /database/contents/, there is nothing
> actually following the the last '/'. Based on this, I do not see why
> the filename should be "contents", at least not based on the rule you
> cite. I am going to give you the benefit of the doubt and assume you
> read my e-mail carefully. If this is true, you must be using a
> different idea of 'last' than me, or in an alternative context where
> it actually refers to the second to last. If this is the case, the
> write up is definitely not clear and I would like a further elaboration.
> To reiterate, I don't know quite what to make of the following list of
> 'special cases':
> / In this case, the simple name will be dir
> foo/ In this case, the simple name will be foo
> foo/. In this case, the simple name will be dot
> foo/.. In this case, the simple name will be dotdot
> I was assuming, though not with absolute certainty, that these
> exceptions refer to the entire URI, i.e. if the URI is just "/", the
> file name is "dir." However, it's not quite clear what foo/ means,
> since for a URI like /database/contents/, it would seem the filename
> would be "/database/contents" but that doesn't look quite right. This
> is the particular case I decided to check. I thought it possible that
> instead the filename might be merely "contents", based on the idea
> that "foo" was a generic variable meant *only* as substitution for the
> last directory (in which case the write up should have been explicit
> in specifying that "foo/" was actually more like
> "/directory/directory/[...etc]/foo/." But your e-mail, while choosing
> the 2nd option, gives a completely different explanation than I don't
> understand at all. I'm really tired from all the projects I'm working
> on concurrently and I'll admit I am not fully literate at this point,
> but even so, I would opine that the write up and the explanation you
> gave are not clear and that my question merits a more detailed
> On 10/24/07, *Daniel Killebrew* <dank at eecs.berkeley.edu
> <mailto:dank at eecs.berkeley.edu>> wrote:
> Nescio Nomen wrote:
> > Once the client has retrieved an item from the server (via a 200 OK
> > reply), it constructs a local file name
> > into which to store the item. The new file name is the simple
> name of
> > the URI, i.e., all the characters
> > following the last '/'. This handles all but a few special cases. In
> > these special cases, your client must create
> > these files according the simple names listed below.
> > / In this case, the simple name will be dir
> > foo/ In this case, the simple name will be foo
> > I don't understand that case. What's it supposed to catch?
> > Is foo just a generic variable that stands for "any and all
> > before the last slash?"
> > So, for this request URI:
> > /database/contents/
> > foo would be:
> > /database/contents
> From the spec:
> The new file name is the simple name of the URI, i.e., all the
> following the last '/'.
> therefore '/database/' is not part of "all the characters
> following the
> last /"
> so 'contents' would be the filename.
> Please rid a bit more closely before asking questions.
> > Is that correct?
> > _______________________________________________
> > ee122 mailing list
> > ee122 at mailman.ICSI.Berkeley.EDU
> <mailto:ee122 at mailman.ICSI.Berkeley.EDU>
> > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
More information about the ee122