Waldek Hebisch wrote:
A solution would be to store the expanded file name (i.e., turn it into an absolute path whenever possible -- I currently don't know any case where it wouldn't be possible).
Fails if current directory is deleted.
Right. But then opening the file again will fail anyway ...
Of course, this wouldn't be strictly BP compatible, but I wonder if this is a "good" or "bad" incompatibility. (Of course, the difference would be subtler and more confusing if there actually was a file `test.dat' in the new directory.) Also, clearly a new `Assign' statement after the change of directory would refer to the new directory, as would be expected.
I expect to be able to move (rename) a directory in which a programm is running without disruption, provided the program uses relatiove paths in subdirectories. Change to absolute paths would break such assumption.
I see, this is a valid point.
I personaly always did `Assign' just before `Reset' or `Rewrite' and expect most programs to do the same. IMHO opening a file should be an atomic operation and splitting opening into `Assign' and `Reset' is prone to races and unexpected side effects.
We could discuss this, but since both EP (bindings) and BP (Assign) work this way, we don't really have a choice here ...
Note that current semantic does give a warranty: file with simple name will be open in current directory. Proposed change introduces a race: file will be open in the directory which has the name current direcory had at `Assign' time. Even if program stays in the same directory the name may change.
In short: I think that only tiny fraction of programs will "benefit" and that slightly more programs will be broken. For me clearily benefits do not justify implementing the change.
I tend to agree. Still, there's some strange behaviour:
program Foo;
var f: file of Integer;
begin Assign (f, 'test.dat'); Reset (f); ChDir ('..'); Rewrite (f); end.
Here `test.dat' msut exist when the program starts. If it is readable and writable, the program will use it both times. If it's readonly, the program will create a new file (because it's not writable), and this will be in the new directory. We could think about always reopening the file, but especially for `SeekRead' etc. (EP) this would be rather inefficient I think.
So perhaps we should just accept it (especially since neither EP nor BP seem to really define this case either). "Don't do that then."
Frank