Number: 671

Date: 11-Apr-84 18':46':58

Submitter: masinter.PA

Source: masinter.PA

Subject: rationalize file package information about file location

Assigned To: Masinter

Attn: Release

Status: Fixed

In/By: 

Problem Type: Design - UI

Impact: Moderate

Difficulty: Moderate

Frequency: 

Priority: Hopefully

System: Programming Environment

Subsystem: File Package

Machine: 

Disk: 

Lisp Version: 8-Apr

Source Files: 

Microcode Version: 

Memory Size: 

File Server: 

Server Software Version: 

Disposition: '
["Masinter" " 1-Sep-84 14':00':26" Assigned% To': Attn': Status':(Wish->Fixed)]

Description: Currently, the internal representation of where the '
''external'' source of a file is is pretty ad-hoc. For example, when you '
LOAD a file, it pays attention to the filename in the FILECREATED '
expression. In fact, this turns out to be a non feature in environments '
like Interlisp-D where users tend to move files from one place to '
another quite frequently.'
'
I think the right way of handling this is to remove the pretense that '
the system can keep track of where the file was originally made as a '
meaningful concept. Rather, it should only pay attention to where it '
FOUND the file. To ensure that this is adhered to, we would change the '
file name in FILECREATED to be the generic (internal) file name rather '
than the external name. Secondly, we would make LOAD and LOADFROM etc. '
explicitly store in some kind of a-list database the correspondence '
between internal external etc. files. (This is an off the cuff design '
but it is the simplest.) For example, one list might be just a list of '
''load events''': (internalname externalname filetype loadtype time) in '
reverse order of occurrence. Then we would ensure that those packages '
which were looking up some information about a file would just look it '
up in the ''load event'' database with the appropriate functional '
interface. This would simplify a lot of internal hackery in the file '
package, and also allow us to rationalize what happens when you make a '
file on the floppy, copy it to disk, compile it on the disk, move both '
to the file server, etc. '
'
It would mean tht files wouldn''t have {phylum} built in and the system '
wouldn''t be looking for it all the time. We could remove the hack from '
FINDFILE and every place that was looking at the FILEDATE property.'
If, for performance reasons, the A-list becomes to onerous, we could '
build a cache. This discussion belongs in the one about ''moving files'' '
that somebody submitted.'


Workaround: 

Test Case: 

Edit-By: Masinter

Edit-Date:  1-Sep-84 14':00':26