Re: File-Requests

Roland Rosenfeld (MSD)
15 Sep 1996 21:09:32 +0200

Egor Egorov <> wrote:

> > So my idea is to have one simple map with the shortname on the left
> > and the real name with relative path on the right column like this:

> > ifmai28f.tgz unix/fido/ifmail/ifmail-2.8f.tar.gz
> > if28f77p.tgz unix/fido/ifmail/ifmail-2.8f_to_2.8f-tx7.7.tgz
> > fidopnte.gz linux/fido/FidoPnt-en.txt.gz

> Well, I do not agree. Why ? Look. On my ftp site (link:
> /var/spool/uucppublic -> ~ftp) I have 28566 files.

Without sub-paths? I don't like this because you can't find anything
and I want to use the filebase for UUCP and FTP, too. So I need an
hierarchic tree...

> How do I create such map?

This map was thaugt as an additional feature. You don't have to use
this and if your map is small or empty the files can be found like

Otherwise it shouldn't be a big problem to write nice perl skript
which generates a first map doing some translations (.tar.gz -> .tgz
etc.). After creating this first map you can edit it by hand. Maybe
a second skript would be usefull, which reads the edited map and adds
all new files at the end.

> Next - there is many unix-related files, like for example,
> ifmail-2.8e_to_tx-7.4f.tar.gz. Why do DOS system need this file ?

There are lots of people who are doing Fido with DOS and uses Linux in
addition to this. Maybe someone wants to receive his ifcico here to
switch the mailer from dos to linux ;-)

> This file is for Unix systems only - so why do I need to map such
> name ?

I fear that most Linux users are using Dos-software for Fido...

> next point: you have to keep 8.3 filenames related to dos.

That's why I want to add this map: I can store the long filenames and
pathes on my harddisk and the map makes it possible to request
8.3-Files and to get the File from the tree...
So the dos-user gets his 8.3-File without problems.
Linux users can get the long filenames with path as before.

> Next point: path in filenames IS allowed.

Where did you find this?

FTS-0006 tells me the follwing:

| The .REQ file is simply a text file that contains the files we want
| from the remote system. Those file names can include wildcards, but
| should not contain a path. Optionally, there can be a password if the
| sending system requires one.

Other question: Which mailers are able to request filenames with a
path in it? Some dos software is very restrictive...

> This mean: why not ? I have 28566 files - how do I do non-path
> request ? It will take so much to process it.

That's what the map is for. With a fast database (gdbm or db or
similar) the lookup should talk less than a second. I don't want a
recursive search on runtime but only a lookup.
With the above given map someone can request the file "if28f77p.tgz"
and ifcico will send the file unix/fido/ifmail/ifmail-2.8f_to_2.8f-tx7.7.tgz.

> If you're going to do 28566 links in uucppublic, your filesystem
> will die without inodes.

That's my problem. After reading FTS-0006 I don't like paths in the
the requested filename but these links are the only way to request a
file without path at the moment.

So my idea was to substitute all these links with only one file, which
does not need much space, is searchable very fast and can access the
real file very fast, because the files are stored in a file tree.

> But I have one proposal:

> tar.gz tgz
> -pointlist.gz -pnt.gz

> and so on: common filename parts translation. If somebody freqs
> life.suxx.tar.gz he'll get life_sux.tgz. If smoebody need
> he'll get this_-pnt.gz and so on.

This can be realized with the above map without problems. Simply
write a small perl skript which does this substitution and stores it
in the map.

> Next problem with non-path freqs: suppose I have 28566 files. Sure,
> there is some files with duplicate filenames.

That's fido :-)

> So, if somebody freq file1, 80k - and he need exactly file1, and
> ifcico will find first "file1" - 54678k, not the one, that he needs
> - ups. :))

You have to manipulate the map so that there are no duplicates in the
left column. If I have the files a/README and b/README the map should
look similar to this:
readme a/README
readmeb b/README

So if someone wants to get the second file he has to request READMEB
(everything should be case insesitive).

Don't forget: This map should be an _additional_ way to access the
files. You can request files with paths in parralel to this.



  * Internet: * Fido: 2:2450/42 *