Re: Naming/Format conventions for INDEX files

"Eric A. Anderson" <ea08+@andrew.cmu.edu> Thu, 23 July 1992 22:55 UTC

Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id ab08292; 23 Jul 92 18:55 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa08288; 23 Jul 92 18:55 EDT
Received: from kona.CC.McGill.CA by NRI.Reston.VA.US id aa06139; 23 Jul 92 18:54 EDT
Received: by kona.cc.mcgill.ca (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA24113 on Thu, 23 Jul 92 14:46:34 -0400
Received: from ANDREW.CMU.EDU by kona.cc.mcgill.ca with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA24109 (mail destined for /usr/lib/sendmail -odq -oi -fiafa-request iafa-out) on Thu, 23 Jul 92 14:46:30 -0400
Received: by andrew.cmu.edu (5.54/3.15) id <AA21244> for iafa@cc.mcgill.ca; Thu, 23 Jul 92 14:46:21 EDT
Received: via switchmail; Thu, 23 Jul 1992 14:46:19 -0400 (EDT)
Received: from sinope.esl.acs.cmu.edu via qmail ID </afs/andrew.cmu.edu/service/mailqs/q002/QF.4ePjruW00VQw80b6po>; Thu, 23 Jul 1992 14:44:10 -0400 (EDT)
Received: from sinope.esl.acs.cmu.edu via qmail ID </afs/andrew.cmu.edu/usr3/ea08/.Outgoing/QF.YePjrme00VQwIFl15A>; Thu, 23 Jul 1992 14:44:02 -0400 (EDT)
Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.sinope.esl.acs.cmu.edu.pmax.ul4 via MS.5.6.sinope.esl.acs.cmu.edu.pmax_ul4; Thu, 23 Jul 1992 14:44:02 -0400 (EDT)
Message-Id: <sePjrmC00VQwIFl0wM@andrew.cmu.edu>
Date: Thu, 23 Jul 1992 14:44:02 -0400
From: "Eric A. Anderson" <ea08+@andrew.cmu.edu>
To: iafa@cc.mcgill.ca
Subject: Re: Naming/Format conventions for INDEX files
Cc: de-mirror@informatik.tu-muenchen.de
In-Reply-To: <92Jul23.182053met_dst.167983@dsrbg2.informatik.tu-muenchen.de>
References: <92Jul23.182053met_dst.167983@dsrbg2.informatik.tu-muenchen.de>

Markus Stumpf <stumpf@informatik.tu-muenchen.de> writes:
> In Germany we plan to standardize (sp?) the format and naming of ftp-server
> index files! This is a sensitive area as it should support all OS platforms.
Unfortunately, the cd command neccesary is going to differ depending
on the OS platform.  You may want to consider that problem.
> The current format looks like (comments welcome)
>      512        1991-02-25 19:50        /pub/BSD/4.3-tcpip/
>   447001        1991-02-06 14:10        /pub/BSD/4.3-tcpip/bind-4.8.3.Z
>       31        1992-07-18 15:59        /pub/BSD/386BSD/0.1 -> ../../../public\
> 2/BSD/386BSD/0.1
Looks pretty nice, it would probably be good to have at the front a
type, e.g. l, f, d, etc.  What do you do about devices and things like
that?  Also, the fact that permissions aren't there is a problem.  You
might want to just define the permissions format.
> Now the questions:
> - Do you think this format can be supported on all platforms?
Answered above.
> - What do you think about the format of the "date" field?
>   Should it be changed to a "ls" conforming format (which would make
>   sorting by date really ugly !!)
Format seems fine with me.
> - Is this suitable for ARCHIE (or how complicated would it be to make
>   ARCHIE understand this format; this is a serious aspect as there is a
>   German ARCHIE-Server under construction ;-) )
You could write a filter that would convert, you'd have to fake the
permissions on the files which is problematical at best.  Beyond that
though you shouldn't have substantial problems.  Initially though
you'd be better off still providing ls-lR.Z files
>
> No proposals on the names so far!
> To reduce net-load we would like to urge each ftp-site to generate daily
> and/or weekly diffs of their index files. This would also reduce the amount
> of work to update the ARCHIE database we hope!
Unless something has changed in 3.0, archie sites will still have to
remove the entire site and re-enter it.  On the other hand, it's not a
whole lot of work to do that now, and 3.0 is supposed to make enters
go much faster.
	-ERic
*********************************************************
"Overhead, without any fuss, the stars were going out."
           -The Nine Billion Names of God
"Yes, you're very smart.  Shut up."
           -In "The Princess Bride"
*********************************************************