-
Notifications
You must be signed in to change notification settings - Fork 1
/
CHANGES
122 lines (87 loc) · 4.44 KB
/
CHANGES
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
118
119
120
121
122
- Get rid of master_pipe. Spread functionality into tasks, and the app
should just keep a global of the current task.
- We currently freeze when the transfer is cancelled. That's bad.
- rzh -q: tell current rzh to quit
(doesn't matter how deep into other machines you are; this bangs
you right back up to your most recent rzh).
- rzh -u: return to the next machine upward. ^D or rzh -q to move downward.
- rzh -i: tell where downloads are currently going
(not envar hack; literally hit the terminal to find out)
- Add listening for keypresses to idle.c.
- Ensure we make the idle string the right width -- always.
- Add a real message for when a file is skipped.
Should recommend using "sz -y" or "sz -N" to ensure file is sent.
- Could parse the zmodem stream to discover the filename and size
so we can provide a better in-progress display.
Actually, play around with rz -v -v -v first.
- Release 1.0
- Need to worry about overflowing byte counters. Convert them to long longs?
Otherwise the numbers will go wrong after 4 GB transferred.
- Is there any way to get the shell to flush its history? Right now,
starting rzh screws up history (hit up arrow, down, run rzh, hit up
arrow -- notice how the history items are different).
19 Sep 2016:
* Harald Lapp added MacOS compatibility,
20 Apr 2006:
* Branch 0.8 just before the big scary refactoring (that went nowhere).
20 Mar 2006:
* Finally got the last of the known transfer bugs. It now works pretty well!
* Bump version to 0.8.
17 Jun 2005:
* It works! It finally sometimes works.
13 Jun 2005:
* Try forking a new rz process to handle the zmodem transfer.
pdpzm works but it has some boundary case bugs and is excruciatingly slow.
13 Nov 2004: tagged version 0.2 (r27)
* Made zmfr.c modular, sent in patches.
* Added send functionality but it appears very broken.
05 Nov 2004: tagged version 0.1 (r21)
* Switched to the pdpzm library because the lrzsz code is amazingly brittle.
15 Jan 2004:
* First version. Tried to modify lrzsz's rz command to add this feature.
REFACTOR:
There are problems when cancelling the transfer using ^C. Some of the
data hits the screen.
Why does this command stall: ./fireup Makefile < /dev/null
Probably because of shoddy i/o. Need to refactor first.
todo: write some functional tests.
todo: set all buffers to 1 byte and see if we garble anything
todo: set all buffers to 7 bytes (1 larger than start string)
and see if we garble anything
- It's ridiculous to have the fds and pids in the task spec.
Get rid of them, then make all the task specs static. Those are
the classes. Then, pass the fds and pids to task_install to
create the instances.
This will get rid of the duplicate closes.
- Should turn master into just another task. Only difference between
master and regular tasks is that master got added first.
- Move logio into the log library. Need a way for non-fifo parts of
the code to log buffer contents. Clean up logio in zrq.c.
Call it log_buffer or log_data or something.
Maybe never: Make --rz and --shell work.
todo: add specifying command for to use (-c).
(this should help testing because I could do "rzh -c sz ..."
TODO: rzh --up, rzh -u, rzhu, or rzu: move up
TODO: rzh from rsync.
TODO: rzh from tar.
LONG TERM:
- Fifo is overcomplex. Should have used shiftbufs so I don't packetize
the stream more than I should. Switch fifo.c to shiftbuf.c?
No. Instead, finish the netknife infrastructure, then switch it over
to that.
NO NEED:
todo: make expandable fifos so masses of memory will guard against deadlock.
Actually, don't do this. There doesn't seem to be a need.
Especially because zmodem doesn't ever read, it only writes!
todo: there is a slight chance of deadlock when we're installing a new task.
The problem is draining the fifo for the new task. Instead, we should
mark the fifo, and give it the new task to install. Then when the fifo
has drained down to that point, we'll kick it over to the new task
automatically. Right now, fifo_drain is really, really, evil.
NOTE: this should solve the nested task create / sigchild issue.
(this issue is where we receive a sigchld when the buffer contains
data intended for the rz task and data intended for the outer shell.
Who handles the sigchld?)
As it turns out, the deadlock never even comes close to happening and
it's easy enough just to handle the sigchld late. Sure, it would be
more correct to mark the buffer, but this is good enough for now.