Subversion Repositories Spectranet

[/] [trunk/] [tnfs/] [tnfs-protocol.txt] - Blame information for rev 570

Details | Compare with Previous | View Log

Line No. Rev Author Line
1 178 winston
The TNFS protocol
2
=================
3
 
4
Rationale
5
---------
6
Protocols such as NFS (unix) or SMB (Windows) are overly complex for 8 bit
7
systems. While NFS is well documented, it's a complex RPC based protocol.
8
SMB is much worse. It is also a complex RPC based protocol, but it's also
9
proprietary, poorly documented, and implementations differ so much that
10
to get something that works with a reasonable subset of SMB would add a
11
great deal of unwanted complexity. The Samba project has been going for
12
/years/ and they still haven't finished making it bug-for-bug compatible with
13
the various versions of Windows!
14
 
15
At the other end, there's FTP, but FTP is not great for a general file
16
system protocol for 8 bit systems - it requires two TCP sockets for
17
each connection, and some things are awkward in ftp, even if they work.
18
 
19
So instead, TNFS provides a straightforward protocol that can easily be
20
implemented on most 8 bit systems. It's designed to be a bit better than
21
FTP for the purpose of a filesystem, but not as complex as the "big" network
22
filesystem protocols like NFS or SMB.
23
 
24
For a PC, TNFS can be implemented using something like FUSE (no, not the
25
Spectrum emulator, but the Filesystem In Userspace project). This is
26
at least available for most things Unixy (Linux, OS X, some of the BSDs),
27
and possibly by now for Windows also.
28
 
29
Security
30
--------
31
This is not intended to be a proper, secure network file system. If you're
32
storing confidential files on your Speccy, you're barmy :) Encryption,
33
for example, is not supported. However, servers that may be exposed to the
34
internet should be coded in such a way they won't open up the host system
35
to exploits.
36
 
37
Operations supported
38
====================
39
These generally follow the POSIX equivalents. Entries with a * are mandatory
40
for servers to support.
41
 
42
Connection management
43
---------------------
44
mount - Connect to a TNFS filesystem *
45
umount - Disconnect from a TNFS filesystem *
46
 
47
Directories
48
-----------
49
opendir - Opens a directory for reading *
50
readdir - Reads a directory entry *
51
closedir - Closes the directory *
52
rmdir - Removes a directory
53
mkdir - Creates a directory
54
 
55 182 winston
Devices
56
-------
57
size - Get the size of the filesystem *
58
free - Get the remaining free space on the filesystem *
59
 
60 178 winston
Files
61
-----
62
open - Opens a file *
63
read - reads from an open file *
64
write - writes to an open file
65
close - closes a file *
66
stat - gets information about a file *
67
lseek - set the position in the file where the next byte will be read/written
68
chmod - change file access
69
unlink - remove a file
70
 
71
Note: Not all servers have to support all operations - for example, a server
72
on a Spectrum with a microdrive, or +3 floppy won't support
73 197 winston
mkdir/rmdir and will only support limited options for chmod. But
74
a BBC Micro with ADFS would support mkdir/rmdir and more file mode options.
75 178 winston
 
76
The directory delimiter in all cases is a "/". A server running on a filesystem
77
that has a different delimiter will have to translate, for example,
78
on a BBC with ADFS, the / would need to be translated to a "." for the
79
underlying OS operation.
80
 
81
Protocol "on the wire"
82
======================
83
 
84
The lowest common denominator is TNFS over UDP. UDP is the 'mandatory'
85
one because it demands the least of possibly small TCP/IP stacks which may
86
have limited resources for TCP sockets. All TNFS servers must
87
support the protocol on UDP port 16384. TCP is optional.
88
 
89
Each datagram has a header. The header is formatted the same way for all
90
datagrams.
91
 
92
Bytes 0,1       Connection ID (ignored for client's "mount" command)
93 182 winston
Byte  2         Retry number
94 178 winston
Byte  3         Command
95
 
96 182 winston
The connection ID is to add extra identifying information, since the same
97
machine can establish more than one connection to the same server and may
98
do so with different credentials.
99 178 winston
 
100 201 winston
Byte 2 is a sequence number. This allows the receiver to determine whether
101
the datagram it just got is a retry or not. It should be incremented
102
by one for each request sent. Clients should discard datagrams from the
103
server if the sequence number does not match the number that was in
104
the request datagram.
105 178 winston
 
106
The last byte is the command.
107
 
108 182 winston
The remaining data in the datagram are specific to each command. However,
109
any command that may return more than one status (i.e. a command that
110
can be either succeed or fail in one or more way), byte 4 is the
111
status of the command, and further data follows from byte 5.
112 178 winston
 
113 182 winston
Every command should yield exactly one datagram in response. A high
114
level operation (such as a call to read()) asking for a buffer larger
115
than the size of one UDP datagram should manage this with as many requests
116
and responses as is necessary to fill the buffer.
117
 
118
The server can also ask the client to back off. If a server can operate
119
with interrupts enabled while the physical disc is busy, and therefore
120
still be able to process requests, it can tell the client that it is busy
121
and to try again later. In this case, the EAGAIN error code will be
122
returned for whatever command was being tried, and following the error
123
code, will be a 16 bit little endian value giving how long to back off in
124
milliseconds. Servers that have this ability should use it, as the server
125
can then better control contention on a slow device, like a floppy disc,
126
since the server can figure out how many requests clients are trying
127
to make and set the back-off value accordingly. Clients should retry as normal
128
once the back-off time expires.
129
 
130 178 winston
As can be seen from this very simple wire protocol, TNFS is not designed
131 201 winston
for confidentiality or security. You have been warned.
132 178 winston
 
133 182 winston
------------------------------------------------------------------------------
134
 
135 178 winston
TNFS command datagrams
136
======================
137
 
138
Logging on and logging off a TNFS server - MOUNT and UMOUNT commands.
139
---------------------------------------------------------------------
140
 
141
MOUNT - Command ID 0x00
142
-----------------------
143
 
144
Format:
145
Standard header followed by:
146 182 winston
Bytes 4+: 16 bit version number, little endian, LSB = minor, MSB = major
147
          NULL terminated string: mount location
148 178 winston
          NULL terminated string: user id (optional - NULL if no user id)
149
          NULL terminated string: password (optional - NULL if no passwd)
150
 
151
Example:
152
 
153
To mount /home/tnfs on the server, with user id "example" and password of
154 182 winston
"password", using version 1.2 of the protocol:
155
0x0000 0x00 0x00 0x02 0x01 /home/tnfs 0x00 example 0x00 password 0x00
156 178 winston
 
157 182 winston
To mount "a:" anonymously, using version 1.2 of the protocol:
158
0x0000 0x00 0x00 0x02 0x01 a: 0x00 0x00 0x00
159 178 winston
 
160 182 winston
The server responds with the standard header. If the operation was successful,
161
the standard header contains the session number, and the TNFS protocol
162
version that the server is using following the header, followed by the
163
minimum retry time in milliseconds as a little-endian 16 bit number.
164
Clients must respect this minimum retry value, especially for a server
165
with a slow underlying file system such as a floppy disc, to avoid swamping
166
the server. A client should also never have more than one request "in flight"
167
at any one time for any operation where order is important, so for example,
168
if reading a file, don't send a new request to read from a given file handle
169
before completing the last request.
170 178 winston
 
171 182 winston
Example: A successful MOUNT command was carried out, with a server that
172
supports version 2.6, and has a minimum retry time of 5 seconds (5000 ms,
173
hex 0x1388). Session ID is 0xBEEF:
174 178 winston
 
175 182 winston
0xBEEF 0x00 0x00 0x00 0x06 0x02 0x88 0x13
176 178 winston
 
177 182 winston
Example: A failed MOUNT command with error 1F for a version 3.5 server:
178
0x0000 0x00 0x00 0x1F 0x05 0x03
179 178 winston
 
180
UMOUNT - Command ID 0x01
181
------------------------
182
 
183
Format:
184
Standard header only, containing the connection ID to terminate, 0x00 as
185
the sequence number, and 0x01 as the command.
186
 
187
Example:
188
To UMOUNT the filesystem mounted with id 0xBEEF:
189
 
190
0xBEEF 0x00 0x01
191
 
192
The server responds with the standard header and a return code as byte 4.
193
The return code is 0x00 for OK. Example:
194
 
195
0xBEEF 0x00 0x01 0x00
196
 
197
On error, byte 4 is set to the error code, for example, for error 0x1F:
198
 
199
0xBEEF 0x00 0x01 0x1F
200
 
201
DIRECTORIES - Opening, Reading and Closing
202
==========================================
203
Don't confuse this with the ability of having a directory heirachy. Even
204
servers (such as a +3 with a floppy) that don't have heirachical filesystems
205
must support cataloguing a disc, and cataloguing a disc requires opening,
206
reading, and closing the catalogue. It's the only way to do it!
207
 
208 182 winston
OPENDIR - Open a directory for reading - Command ID 0x10
209 178 winston
--------------------------------------------------------
210
 
211
Format:
212 185 winston
Standard header followed by a null terminated absolute path.
213
The path delimiter is always a "/". Servers whose underlying
214
file system uses other delimiters, such as Acorn ADFS, should
215
translate. Note that any recent version of Windows understands "/"
216
to be a path delimiter, so a Windows server does not need
217 178 winston
to translate a "/" to a "\".
218 185 winston
Clients should keep track of their own current working directory.
219 178 winston
 
220
Example:
221 182 winston
0xBEEF 0x00 0x10 /home/tnfs 0x00 - Open absolute path "/home/tnfs"
222 178 winston
 
223
The server responds with the standard header, with byte 4 set to the
224
return code which is 0x00 for success, and if successful, byte 5
225
is set to the directory handle.
226
 
227
Example:
228 182 winston
0xBEEF 0x00 0x10 0x00 0x04 - Successful, handle is 0x04
229
0xBEEF 0x00 0x10 0x1F - Failed with code 0x1F
230 178 winston
 
231 182 winston
READDIR - Reads a directory entry - Command ID 0x11
232 178 winston
---------------------------------------------------
233
 
234
Format:
235
Standard header plus directory handle.
236
 
237
Example:
238 182 winston
0xBEEF 0x00 0x11 0x04 - Read an entry with directory handle 0x04
239 178 winston
 
240 546 winston
The server responds with the standard header, followed by the directory
241
entry. Example:
242 178 winston
 
243 546 winston
0xBEEF 0x17 0x11 0x00 . 0x00 - Directory entry for the current working directory
244
0xBEEF 0x18 0x11 0x00 .. 0x00 - Directory entry for parent
245
0xBEEF 0x19 0x11 0x00 foo 0x00 - File named "foo"
246 178 winston
 
247 546 winston
If the end of directory is reached, or another error occurs, then the
248
status byte is set to the error number as for other commands.
249
0xBEEF 0x1A 0x11 0x21 - EOF
250
0xBEEF 0x1B 0x11 0x1F - Error code 0x1F
251
 
252 182 winston
CLOSEDIR - Close a directory handle - Command ID 0x12
253 178 winston
-----------------------------------------------------
254
 
255
Format:
256
Standard header plus directory handle.
257
 
258 182 winston
Example, closing handle 0x04:
259
0xBEEF 0x00 0x12 0x04
260 178 winston
 
261
The server responds with the standard header, with byte 4 set to the
262
return code which is 0x00 for success, or something else for an error.
263
Example:
264 182 winston
0xBEEF 0x00 0x12 0x00 - Close operation succeeded.
265
0xBEEF 0x00 0x12 0x1F - Close failed with error code 0x1F
266 178 winston
 
267 198 winston
MKDIR - Make a new directory - Command ID 0x13
268
----------------------------------------------
269
 
270
Format:
271
Standard header plus a null-terminated absolute path.
272
 
273
Example:
274
0xBEEF 0x00 0x13 /foo/bar/baz 0x00
275
 
276
The server responds with the standard header plus the return code:
277
0xBEEF 0x00 0x13 0x00 - Directory created successfully
278
0xBEEF 0x00 0x13 0x02 - Directory creation failed with error 0x02
279
 
280
RMDIR - Remove a directory - Command ID 0x14
281
--------------------------------------------
282
 
283
Format:
284
Standard header plus a null-terminated absolute path.
285
 
286
Example:
287
0xBEEF 0x00 0x14 /foo/bar/baz 0x00
288
 
289
The server responds with the standard header plus the return code:
290
0xBEEF 0x00 0x14 0x00 - Directory was deleted.
291
0xBEEF 0x00 0x14 0x02 - Directory delete operation failed with error 0x02
292
 
293 182 winston
-------------------------------------------------------------------------------
294
 
295 188 winston
FILE OPERATIONS
296
===============
297
These typically follow the low level fcntl syscalls in Unix (and Win32),
298
rather than stdio and carry the same names. Note that the z88dk low level
299
file operations also implement these system calls. Also, some calls,
300
such as CREAT don't have their own packet in tnfs since they can be
301
implemented by something else (for example, CREAT is equivalent
302
to OPEN with the O_CREAT flag). Not all servers will support all flags
303 483 winston
for OPEN, but at least O_RDONLY. The mode refers to UNIX file permissions,
304
see the CHMOD command below.
305 188 winston
 
306 494 winston
OPEN - Opens a file - Command 0x29
307 188 winston
----------------------------------
308 483 winston
Format: Standard header, flags, mode, then the null terminated filename.
309 188 winston
Flags are a bit field.
310
 
311 546 winston
The flags are:
312 483 winston
O_RDONLY        0x0001  Open read only
313
O_WRONLY        0x0002  Open write only
314
O_RDWR          0x0003  Open read/write
315
O_APPEND        0x0008  Append to the file, if it exists (write only)
316
O_CREAT         0x0100  Create the file if it doesn't exist (write only)
317
O_TRUNC         0x0200  Truncate the file on open for writing
318
O_EXCL          0x0400  With O_CREAT, returns an error if the file exists
319
 
320 546 winston
The modes are the same as described by CHMOD (i.e. POSIX modes). These
321
may be modified by the server process's umask. The mode only applies
322
when files are created (if the O_CREAT flag is specified)
323
 
324 188 winston
Examples:
325
Open a file called "/foo/bar/baz.bas" for reading:
326
 
327 546 winston
0xBEEF 0x00 0x29 0x0001 0x0000 /foo/bar/baz.bas 0x00
328 188 winston
 
329
Open a file called "/tmp/foo.dat" for writing, creating the file but
330 546 winston
returning an error if it exists. Modes set are S_IRUSR, S_IWUSR, S_IRGRP
331
and S_IWOTH (read/write for owner, read-only for group, read-only for
332
others):
333 188 winston
 
334 546 winston
0xBEEF 0x00 0x29 0x0102 0x01A4 /tmp/foo.dat 0x00
335 188 winston
 
336
The server returns the standard header and a result code in response.
337
If the operation was successful, the byte following the result code
338
is the file descriptor:
339
 
340 546 winston
0xBEEF 0x00 0x29 0x00 0x04 - Successful file open, file descriptor = 4
341
0xBEEF 0x00 0x29 0x01 - File open failed with "permssion denied"
342 188 winston
 
343 494 winston
(HISTORICAL NOTE: OPEN used to have command id 0x20, but with the
344
addition of extra flags, the id was changed so that servers could
345
support both the old style OPEN and the new OPEN)
346
 
347 188 winston
READ - Reads from a file - Command 0x21
348
---------------------------------------
349
Reads a block of data from a file. Consists of the standard header
350
followed by the file descriptor as returned by OPEN, then a 16 bit
351
little endian integer specifying the size of data that is requested.
352 570 winston
 
353 188 winston
The server will only reply with as much data as fits in the maximum
354 570 winston
TNFS datagram size of 1K when using UDP as a transport. For the
355
TCP transport, sequencing and buffering etc. are just left up to
356
the TCP stack, so a READ operation can return blocks of up to 64K.
357 188 winston
 
358 570 winston
If there is less than the size requested remaining in the file,
359
the server will return the remainder of the file.  Subsequent READ
360
commands will return the code EOF.
361
 
362 188 winston
Examples:
363
Read from fd 4, maximum 256 bytes:
364
 
365
0xBEEF 0x00 0x21 0x04 0x00 0x01
366
 
367
The server will reply with the standard header, followed by the single
368
byte return code, the actual amount of bytes read as a 16 bit unsigned
369
little endian value, then the data, for example, 256 bytes:
370
 
371
0xBEEF 0x00 0x21 0x00 0x00 0x01 ...data...
372
 
373
End-of-file reached:
374
 
375
0xBEEF 0x00 0x21 0x21
376
 
377
WRITE - Writes to a file - Command 0x22
378
---------------------------------------
379
Writes a block of data to a file. Consists of the standard header,
380
followed by the file descriptor, followed by a 16 bit little endian
381
value containing the size of the data, followed by the data. The
382
entire message must fit in a single datagram.
383
 
384
Examples:
385
Write to fd 4, 256 bytes of data:
386
 
387
0xBEEF 0x00 0x22 0x04 0x00 0x01 ...data...
388
 
389
The server replies with the standard header, followed by the return
390
code, and the number of bytes actually written. For example:
391
 
392
0xBEEF 0x00 0x22 0x00 0x00 0x01 - Successful write of 256 bytes
393
0xBEEF 0x00 0x22 0x06 - Failed write, error is "bad file descriptor"
394
 
395
CLOSE - Closes a file - Command 0x23
396
------------------------------------
397
Closes an open file. Consists of the standard header, followed by
398
the file descriptor. Example:
399
 
400
0xBEEF 0x00 0x23 0x04 - Close file descriptor 4
401
 
402
The server replies with the standard header followed by the return
403
code:
404
 
405
0xBEEF 0x00 0x23 0x00 - File closed.
406
0xBEEF 0x00 0x23 0x06 - Operation failed with EBADF, "bad file descriptor"
407
 
408 197 winston
 
409
STAT - Get information on a file - Command 0x24
410
-----------------------------------------------
411
Reads the file's information, such as size, datestamp etc. The TNFS
412
stat contains less data than the POSIX stat - information that is unlikely
413
to be of use to 8 bit systems are omitted.
414
The request consists of the standard header, followed by the full path
415
of the file to stat, terminated by a NULL. Example:
416
 
417
0xBEEF 0x00 0x24 /foo/bar/baz.txt 0x00
418
 
419
The server replies with the standard header, followed by the return code.
420
On success, the file information follows this. Stat information is returned
421 291 winston
in this order. Not all values are used by all servers. At least file
422
mode and size must be set to a valid value (many programs depend on these).
423 197 winston
 
424
File mode       - 2 bytes: file permissions - little endian byte order
425
uid             - 2 bytes: Numeric UID of owner
426
gid             - 2 bytes: Numeric GID of owner
427
size            - 4 bytes: Unsigned 32 bit little endian size of file in bytes
428
atime           - 4 bytes: Access time in seconds since the epoch, little end.
429
mtime           - 4 bytes: Modification time in seconds since the epoch,
430
                           little endian
431
ctime           - 4 bytes: Time of last status change, as above.
432
uidstring       - 0 or more bytes: Null terminated user id string
433
gidstring       - 0 or more bytes: Null terminated group id string
434
 
435
Fields that don't apply to the server in question should be left as 0x00.
436
The ┬┤mtime' field and 'size' fields are unsigned 32 bit integers.
437
The uidstring and gidstring are helper fields so the client doesn't have
438
to then ask the server for the string representing the uid and gid.
439
 
440
File mode flags will be most useful for code that is showing a directory
441
listing, and for programs that need to find out what kind of file (regular
442
file or directory, etc) a particular file may be. They follow the POSIX
443
convention which is:
444
 
445
Flags           Octal representation
446
S_IFMT          0170000         Bitmask for the file type bitfields
447
S_IFSOCK        0140000         Is a socket
448
S_IFLNK         0120000         Is a symlink
449
S_IFREG         0100000         Is a regular file
450
S_IFBLK         0060000         block device
451
S_IFDIR         0040000         Directory
452
S_IFCHR         0020000         Character device
453
S_IFIFO         0010000         FIFO
454
S_ISUID         0004000         set UID bit
455
S_ISGID         0002000         set group ID bit
456
S_ISVTX         0001000         sticky bit
457
S_IRWXU         00700           Mask for file owner permissions
458
S_IRUSR         00400           owner has read permission
459
S_IWUSR         00200           owner has write permission
460
S_IXUSR         00100           owner has execute permission
461
S_IRGRP         00040           group has read permission
462
S_IWGRP         00020           group has write permission
463
S_IXGRP         00010           group has execute permission
464
S_IROTH         00004           others have read permission
465
S_IWOTH         00002           others have write permission
466
S_IXOTH         00001           others have execute permission
467
 
468
Most of these won't be of much interest to an 8 bit client, but the
469
read/write/execute permissions can be used for a client to determine whether
470
to bother even trying to open a remote file, or to automatically execute
471
certain types of files etc. (Further file metadata such as load and execution
472
addresses are platform specific and should go into a header of the file
473
in question). Note the "trivial" bit in TNFS means that the client is
474
unlikely to do anything special with a FIFO, so writing to a file of that
475
type is likely to have effects on the server, and not the client! It's also
476
worth noting that the server is responsible for enforcing read and write
477
permissions (although the permission bits can help the client work out
478
whether it should bother to send a request).
479
 
480 198 winston
LSEEK - Seeks to a new position in a file - Command 0x25
481
--------------------------------------------------------
482
Seeks to an absolute position in a file, or a relative offset in a file,
483
or to the end of a file.
484
The request consists of the header, followed by the file descriptor,
485
followed by the seek type (SEEK_SET, SEEK_CUR or SEEK_END), followed
486
by the position to seek to. The seek position is a signed 32 bit integer,
487
little endian. (2GB file sizes should be more than enough for 8 bit
488
systems!)
489
 
490
The seek types are defined as follows:
491
0x00            SEEK_SET - Go to an absolute position in the file
492
0x01            SEEK_CUR - Go to a relative offset from the current position
493
0x02            SEEK_END - Seek to EOF
494
 
495
Example:
496
 
497
File descriptor is 4, type is SEEK_SET, and position is 0xDEADBEEF:
498
0xBEEF 0x00 0x25 0x04 0x00 0xEF 0xBE 0xAD 0xDE
499
 
500
Note that clients that buffer reads for single-byte reads will have
501
to make a calculation to implement SEEK_CUR correctly since the server's
502
file pointer will be wherever the last read block made it end up.
503
 
504
UNLINK - Unlinks (deletes) a file - Command 0x26
505
------------------------------------------------
506
Removes the specified file. The request consists of the header then
507
the null terminated full path to the file. The reply consists of the
508
header and the return code.
509
 
510
Example:
511
Unlink file "/foo/bar/baz.bas"
512
0xBEEF 0x00 0x26 /foo/bar/baz.bas 0x00
513
 
514
CHMOD - Changes permissions on a file - Command 0x27
515
----------------------------------------------------
516
Changes file permissions on the specified file, using POSIX permissions
517
semantics. Not all permissions may be supported by all servers - most 8
518
bit systems, for example, may only support removing the write bit.
519
A server running on something Unixish will support everything.
520
The request consists of the header, followed by the 16 bit file mode,
521
followed by the null terminated filename. Filemode is sent as a little
522
endian value. See the Unix manpage for chmod(2) for further information.
523
 
524
File modes are as defined by POSIX. The POSIX definitions are as follows:
525
 
526
Flag      Octal Description
527
S_ISUID   04000 set user ID on execution
528
S_ISGID   02000 set group ID on execution
529
S_ISVTX   01000 sticky bit
530
S_IRUSR   00400 read by owner
531
S_IWUSR   00200 write by owner
532
S_IXUSR   00100 execute/search by owner
533
S_IRGRP   00040 read by group
534
S_IWGRP   00020 write by group
535
S_IXGRP   00010 execute/search by group
536
S_IROTH   00004 read by others
537
S_IWOTH   00002 write by others
538
S_IXOTH   00001 execute/search by others
539
 
540
Example: Set permissions to 755 on /foo/bar/baz.bas:
541
0xBEEF 0x00 0x27 0xED 0x01 /foo/bar/baz.bas
542
 
543
The reply is the standard header plus the return code of the chmod operation.
544
 
545 288 winston
RENAME - Moves a file within a filesystem - Command 0x28
546
--------------------------------------------------------
547
Renames a file (or moves a file within a filesystem - it must be possible
548
to move a file to a different directory within the same FS on the
549
server using this command).
550
The request consists of the header, followed by the null terminated
551
source path, and the null terminated destination path.
552
 
553
Example: Move file "foo.txt" to "bar.txt"
554
0xBEEF 0x00 0x28 foo.txt 0x00 bar.txt 0x00
555
 
556 199 winston
DEVICE OPERATIONS
557
=================
558
These operations get information about the device that is mounted.
559
 
560
SIZE - Requests the size of the mounted filesystem - Command 0x30
561
-----------------------------------------------------------------
562
Finds the size, in kilobytes, of the filesystem that is currently mounted.
563
The request consists of a standard header and nothing more.
564
 
565
Example:
566
0xBEEF 0x00 0x30
567
 
568
The reply is the standard header, followed by the return code, followed
569
by a 32 bit little endian integer which is the size of the filesystem
570
in kilobytes, for example:
571
 
572
0xBEEF 0x00 0x30 0x00 0xD0 0x02 0x00 0x00 - Filesystem is 720kbytes
573
0xBEEF 0x00 0x30 0xFF - Request failed with error code 0xFF
574
 
575
FREE - Requests the amount of free space on the filesystem - Command 0x31
576
-------------------------------------------------------------------------
577
Finds the size, in kilobytes, of the free space remaining on the mounted
578
filesystem. The request consists of the standard header and nothing more.
579
 
580
Example:
581
0xBEEF 0x00 0x31
582
 
583
The reply is as for SIZE - the standard header, return code, and little
584
endian integer for the free space in kilobytes, for example:
585
 
586
0xBEEF 0x00 0x31 0x00 0x64 0x00 0x00 0x00 - There is 64K free.
587
0xBEEF 0x00 0x31 0x1F - Request failed with error 0x1F
588
 
589 182 winston
LIST OF VALID RETURN CODES
590
==========================
591
Note not all servers may return all codes. For example, a server on a machine
592
that doesn't have named pipes will never return ESPIPE.
593
 
594
ID      POSIX equiv     Description
595
0x00                    Success
596
0x01    EPERM           Operation not permitted
597
0x02    ENOENT          No such file or directory
598
0x03    EIO             I/O error
599
0x04    ENXIO           No such device or address
600
0x05    E2BIG           Argument list too long
601
0x06    EBADF           Bad file number
602
0x07    EAGAIN          Try again
603
0x08    ENOMEM          Out of memory
604
0x09    EACCES          Permission denied
605
0x0A    EBUSY           Device or resource busy
606
0x0B    EEXIST          File exists
607
0x0C    ENOTDIR         Is not a directory
608
0x0D    EISDIR          Is a directory
609
0x0E    EINVAL          Invalid argument
610
0x0F    ENFILE          File table overflow
611
0x10    EMFILE          Too many open files
612
0x11    EFBIG           File too large
613
0x12    ENOSPC          No space left on device
614
0x13    ESPIPE          Attempt to seek on a FIFO or pipe
615
0x14    EROFS           Read only filesystem
616
0x15    ENAMETOOLONG    Filename too long
617
0x16    ENOSYS          Function not implemented
618
0x17    ENOTEMPTY       Directory not empty
619
0x18    ELOOP           Too many symbolic links encountered
620
0x19    ENODATA         No data available
621
0x1A    ENOSTR          Out of streams resources
622
0x1B    EPROTO          Protocol error
623
0x1C    EBADFD          File descriptor in bad state
624
0x1D    EUSERS          Too many users
625
0x1E    ENOBUFS         No buffer space available
626
0x1F    EALREADY        Operation already in progress
627
0x20    ESTALE          Stale TNFS handle
628 185 winston
0x21    EOF             End of file
629 182 winston
0xFF                    Invalid TNFS handle
630