-
Notifications
You must be signed in to change notification settings - Fork 7
/
Copy pathur2.txt
118 lines (87 loc) · 5.46 KB
/
ur2.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
Special support for the TS-DOS and SARDIN buttons in Ultimate ROM II
A few "magic" filenames that have the following properties:
* Names: DOS100.CO, DOS200.CO, DOSNEC.CO, SAR100.CO, SAR200.CO
(1)
* If client tries to open(read), and file doesn't exist in cwd, silently
succeed anyway and supply contents from the same file from the share root
dir instead. Failing that, get from the app lib dir (/usr/local/lib/dl).
* Do not include in directory listing unless it actually exists in cwd.
* Do not supply substitute contents if file actually exists in cwd.
If client tries to load a file that actually exists in cwd,
it should work as normal, not sustitute the contents from some other file.
X Do not apply the remapping/translation to open(write) or open(append).
If client tries to save a file, it should work as normal,
not overwite the copy in the share root!
(2)
X DO allow overwriting the share root copy if the client is actually in
the share root dir. Not implemented yet but no problem to.
* Don't even look if not in "floppy compat" mode (dot_offset=6).
There is no UR-II for CP/M or WP-2 or Z88 any other kind of client.
TS-LOAD, Sardine/SarDOS, and UR-II are the only users of this feature.
Explaination
Ultimate ROM II has a "TS-DOS" button that tries to load a file named
"DOS100.CO" on the fly.
(or DOS200.CO for TANDY Model 200, or DOSNEC.CO for NEC PC-8201/PC-8300)
UR-II does not know about directories, and does not do anything to try
to cd to the root dir before trying to open the file.
On a real drive, this works fine. If a disk simply contains a copy of
the file, then the open() works and so the TS-DOS button works.
On an emulated drive that can cd into sub-directories, it's possible for
the user to launch TS-DOS, cd into a sub-directory that does not contain
a copy of DOS100.CO, and then exit TS-DOS.
Now the server is chdir'd into a directory that does not contain DOS100.CO,
and the user has exited TS-DOS, which unloaded their temporary copy of
DOS100.CO from ram. If the user tries to use the TS-DOS button again,
the server just gets a request to open "DOS100.CO", which does not exist,
and so the user has no way to load TS-DOS again.
So this version of dlplus has special support so that whenever one of those
particular filenames are requested, if it isn't found in the current dir
naturally like any other file, then the server silently also looks in the
share root dir, and failing that finally gets it from /usr/local/lib/dl, so
the load always succeeds no matter if the user has CD'd into some subdirectory,
no matter if there is even no copy of DOS100.CO anywhere in the share tree.
All the above also applies similarly to SAR100.CO/SAR200.CO,
which is loaded by the SARDIN button in UR-II.
-------------------------------------------------------------------------------
(1) There are actually more filenames in the list, but the rest don't actually
exist. The rest of the recognized filenames are DOSM10.CO, DOSK85.CO,
SARNEC.CO, SARM10.CO, and SARK85.CO.
M10.CO & K85.CO would be TS-DOS & Sardine for Olivetti and Kyotronic,
which probably never existed. If they did exist, these are just my
guesses what the filenames would be. Maybe they will turn up some day.
(2) *Not quite possible*
The magic files don't get overwritten, so it's only an annoying cosmetic
problem, but there's basically no way around it unless we can detect
something unique about the way UR-II requests DOS100.CO vs any other client.
If we could do that, then we could answer UR-II always with "file exists"
and answer any other client honestly, which would allow a normal client to
create and write to the file. I don't think there is any such tell, but maybe.
The problem is the tpdd protocol requires the server to say if a file
exists *before* the client says what they intend to do with it.
We don't know that they want to write until it's too late to give
the right response to allow writing.
The sequence of events when a client accesses a file goes like this:
Client: I want to do something with a file named "DOS100.CO".
Server: OK. DOS100.CO does not exist.
Client: open for writing.
Server: OK.
Client: Write this data ......
Server: OK.
Except in the special case of DOS100.CO, that first server response
always has to say "OK. DOS100.CO exists and is N bytes".
If we answer set-name with null, then the magic LOAD doesn't work
because we told the client that the file doesn't exist.
If we answer set-name with the filename & size, then SAVE doesn't work
because we told the client that the file already exists.
It's far more frequently needed, and more useful & important to load
DOS___.CO than to save it, so dl defaults to make load work. And if the
user does actually answer "Overwrite" when trying to save, it harmlessly
fails to overwrite the real file in /usr/local/lib/dl due to permissions.
This could be made slightly better by recognizing the special filename
after the set-name step, and doing something different during open(write)
if that's what ends up happening. Like write to the current dir instead
of trying to overwite the magic file. The user would still get an annoying
"Overwrite? Append? Cancel?" message, but at least if they just ignore
that and choose Overwite, the file would appear in the current dir
otherwise as expected. This last little bit is not implemented currently.
-----------