Number: 509

Date:  6-Apr-84  3':49':21

Submitter: le.pasa

Source: Tom Lipkis <LIPKIS@USC-ISIF.ARPA>

Subject: Problems when name in FILECREATED expression different from loaded file name

Assigned To: 

Attn: 

Status: Fixed

In/By: 

Problem Type: Bug

Impact: Serious

Difficulty: 

Frequency: 

Priority: Perhaps

System: Programming Environment

Subsystem: File Package

Machine: 1100

Disk: 

Lisp Version:  FUGUE4

Source Files: 

Microcode Version: 

Memory Size: 

File Server: 

Server Software Version: 

Disposition: '
[tl': changed attn to kaplan.pa only]'
[mjs 4/6/84 changed system, subsystem, subject]'
[this is the same as numerous other more recent ARS that got fixed'
["masinter" "27-Aug-84 23':00':23" Attn': Status':(Open->Fixed) Disposition':]

Description: '
There is a problem parsing filenames from different systems in'
FILECREATED expressions that has caused some people here some grief, and may'
be related to SHahn''s problem.  If a file is made from (say) Interlisp-VAX,'
and loaded into Interlisp-D, the filename in the FILECREATED has a syntax'
that Interlisp-D doesn''t know how to parse.  As a result, the various file'
properties (FILE, FILEDATES, etc.), as well as the COMS, can get put on the'
wrong atom.  If a MAKEFILE is done, the result will then be an empty file,'
since it can''t find the old COMS.  There is no indication that this has'
happened (except that the MAKEFILE goes very fast), so its easy to lose'
work.  In other circumstances (depending on the particular filename syntax),'
you get a BAD FILENAME error.'
'
	The problem is that the FILECREATED reflects the name the file was'
created with, which is not necessarily its current name.  Interlisp-VAX'
doesn''t have this problem because it notices the name used to load the file,'
and fixes up the properties and COMS accordingly.  DDyer sent this code to'
PARC some time ago, but it never appeared in Interlisp-D.  While his changes'
do change the semantics of the file package, it seems like a change for the'
better.'
----'
'
ADDITIONAL INFORMATION;'
The problem is unrelated to any file server, only to Interlisp''s'
processing of the FILECREATED expression, and to the varying filename syntax'
across different implementations (D, J, VAX).'
'
	The most serious problem is as follows.  If I MAKEFILE(FOO) in'
Interlisp-vax, I get a file whose FILECREATED says /usr4/lipkis/FOO.;1 .'
This file is accessible to Interlisp-D, under the name'
{VAXA}</usr4/lipkis>foo.  If I LOAD({VAXA}</usr4/lipkis>foo) into'
Interlisp-D, the FILEMAP property goes on FOO, but the FILEDATES and FILE'
properties go on the atom /usr4/lipkis/FOO, because Interlisp-D doesn''t know'
how to parse the name in the FILECREATED.  (The FILEMAP and FILEDATES both'
have the filename as {VAXA}</USR4/LIPKIS>FOO, but the FILE property is'
((/usr4/lipkis/FOOCOMS .  T)).  The coms are actually on FOOCOMS, of'
course.)  Doing MAKEFILE(FOO) at this point produces a file containing only'
a FILECREATED and a FILEMAP, and none of the original contents, presumably'
because it couldn''t find the coms.  There is no indication (other than the'
speed of the MAKEFILE) that the contents of FOO were not written out.'
'
	This is similar to a long standing problem involving renaming (or'
copying) a file outside of lisp.  When the file is LOADed, the properties'
end up split between the old and new names as above, but in this case'
MAKEFILE will work properly (though I''m not sure why).'
'
	I have seen slightly different effects with files imported from'
Interlisp-J, whose filenames have similar syntax to IFS names.  My'
normal procedure when importing files is to load the sources and do a'
MAKEFILE(... NEW) before anything else, so that the file package knows'
where the file really is.  However, even that doesn''t work in the first'
example above.'
'
	The basic problem is that files are not always accessed under the'
name with which they were created, but Interlisp assumes they are when it'
uses the FILECREATED.  Interlisp-vax does not have this problem because it'
doesn''t make that assumption.  I don''t know all the details (DDyer or Ray'
Bates can supply them), but when a file is loaded, the coms and properties'
are all put on the atom which reflects the current name of the file, not the'
FILECREATED.  (Thus one implementation does not have to be able to parse'
filenames used by another implementation (I think).)  In the case where a'
file has been moved from one system to another, or is being accessed with a'
different syntax as in the first example, this completely fixes the problem.'
If the name has changed (whether or not the file was moved to another'
system), it puts everything on the new name.  This is an incompatible'
change, as the coms will be on a different variable than indicated in the'
file, but the current situation where the coms for file BAR are in FOOCOMS'
isn''t all that great anyway.'
'
-----'
'
Date':  5 Apr 84 15':16 PST'
From': vanMelle.pa'
Subject': Re': AR#509'
To': LispSupport, 1100Support.pasa'
'
This problem is FilePkg, attn Kaplan.  I think it is largely (but perhaps not completely) superseded by another AR--"Filepkg confused by name in FILECREATED expression being different than name file was loaded under". '


Workaround: 

Test Case: 

Edit-By: masinter

Edit-Date: 27-Aug-84 23':00':25