Subversion Repositories Spectranet

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

Go to most recent revision | 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
The server responds with the standard header, with the sequence number
241
set to the directory entry number. Following the standard header is
242
a NULL terminated string, which is the directory entry. Example:
243 182 winston
0xBEEF 0x00 0x11 . 0x00 - Directory entry for the current working directory
244
0xBEEF 0x00 0x11 .. 0x00 - Directory entry for parent
245
0xBEEF 0x00 0x11 foo 0x00 - File named "foo"
246 178 winston
 
247
If the end of directory is reached, or other error is reached, the
248
header is sent as above, but byte 4 is set to 0x00 and byte 5 is set to
249
the code (either EOF or an error):
250 182 winston
0xBEEF 0x00 0x11 0x00 0x01 - EOF
251
0xBEEF 0x00 0x11 0x00 0x1F - Error code 0x1F
252 178 winston
 
253 182 winston
CLOSEDIR - Close a directory handle - Command ID 0x12
254 178 winston
-----------------------------------------------------
255
 
256
Format:
257
Standard header plus directory handle.
258
 
259 182 winston
Example, closing handle 0x04:
260
0xBEEF 0x00 0x12 0x04
261 178 winston
 
262
The server responds with the standard header, with byte 4 set to the
263
return code which is 0x00 for success, or something else for an error.
264
Example:
265 182 winston
0xBEEF 0x00 0x12 0x00 - Close operation succeeded.
266
0xBEEF 0x00 0x12 0x1F - Close failed with error code 0x1F
267 178 winston
 
268 198 winston
MKDIR - Make a new directory - Command ID 0x13
269
----------------------------------------------
270
 
271
Format:
272
Standard header plus a null-terminated absolute path.
273
 
274
Example:
275
0xBEEF 0x00 0x13 /foo/bar/baz 0x00
276
 
277
The server responds with the standard header plus the return code:
278
0xBEEF 0x00 0x13 0x00 - Directory created successfully
279
0xBEEF 0x00 0x13 0x02 - Directory creation failed with error 0x02
280
 
281
RMDIR - Remove a directory - Command ID 0x14
282
--------------------------------------------
283
 
284
Format:
285
Standard header plus a null-terminated absolute path.
286
 
287
Example:
288
0xBEEF 0x00 0x14 /foo/bar/baz 0x00
289
 
290
The server responds with the standard header plus the return code:
291
0xBEEF 0x00 0x14 0x00 - Directory was deleted.
292
0xBEEF 0x00 0x14 0x02 - Directory delete operation failed with error 0x02
293
 
294 182 winston
-------------------------------------------------------------------------------
295
 
296 188 winston
FILE OPERATIONS
297
===============
298
These typically follow the low level fcntl syscalls in Unix (and Win32),
299
rather than stdio and carry the same names. Note that the z88dk low level
300
file operations also implement these system calls. Also, some calls,
301
such as CREAT don't have their own packet in tnfs since they can be
302
implemented by something else (for example, CREAT is equivalent
303
to OPEN with the O_CREAT flag). Not all servers will support all flags
304 483 winston
for OPEN, but at least O_RDONLY. The mode refers to UNIX file permissions,
305
see the CHMOD command below.
306 188 winston
 
307 494 winston
OPEN - Opens a file - Command 0x29
308 188 winston
----------------------------------
309 483 winston
Format: Standard header, flags, mode, then the null terminated filename.
310 188 winston
Flags are a bit field.
311
The filemodes are:
312
 
313 483 winston
O_RDONLY        0x0001  Open read only
314
O_WRONLY        0x0002  Open write only
315
O_RDWR          0x0003  Open read/write
316 188 winston
 
317
The flags are:
318
 
319 483 winston
O_APPEND        0x0008  Append to the file, if it exists (write only)
320 188 winston
 
321 483 winston
O_CREAT         0x0100  Create the file if it doesn't exist (write only)
322
O_TRUNC         0x0200  Truncate the file on open for writing
323
O_EXCL          0x0400  With O_CREAT, returns an error if the file exists
324
 
325 188 winston
Examples:
326
Open a file called "/foo/bar/baz.bas" for reading:
327
 
328 483 winston
0xBEEF 0x00 0x20 0x0001 0x0000 /foo/bar/baz.bas 0x00
329 188 winston
 
330
Open a file called "/tmp/foo.dat" for writing, creating the file but
331
returning an error if it exists:
332
 
333 483 winston
0xBEEF 0x00 0x20 0x0102 0x0000 /tmp/foo.dat 0x00
334 188 winston
 
335
The server returns the standard header and a result code in response.
336
If the operation was successful, the byte following the result code
337
is the file descriptor:
338
 
339
0xBEEF 0x00 0x20 0x00 0x04 - Successful file open, file descriptor = 4
340
0xBEEF 0x00 0x20 0x01 - File open failed with "permssion denied"
341
 
342 494 winston
(HISTORICAL NOTE: OPEN used to have command id 0x20, but with the
343
addition of extra flags, the id was changed so that servers could
344
support both the old style OPEN and the new OPEN)
345
 
346 188 winston
READ - Reads from a file - Command 0x21
347
---------------------------------------
348
Reads a block of data from a file. Consists of the standard header
349
followed by the file descriptor as returned by OPEN, then a 16 bit
350
little endian integer specifying the size of data that is requested.
351
The server will only reply with as much data as fits in the maximum
352
TNFS datagram size of 1K. If there is less than the size requested
353
remaining in the file, the server will return the remainder of the file.
354
Subsequent READ commands will return the code EOF.
355
 
356
Examples:
357
Read from fd 4, maximum 256 bytes:
358
 
359
0xBEEF 0x00 0x21 0x04 0x00 0x01
360
 
361
The server will reply with the standard header, followed by the single
362
byte return code, the actual amount of bytes read as a 16 bit unsigned
363
little endian value, then the data, for example, 256 bytes:
364
 
365
0xBEEF 0x00 0x21 0x00 0x00 0x01 ...data...
366
 
367
End-of-file reached:
368
 
369
0xBEEF 0x00 0x21 0x21
370
 
371
WRITE - Writes to a file - Command 0x22
372
---------------------------------------
373
Writes a block of data to a file. Consists of the standard header,
374
followed by the file descriptor, followed by a 16 bit little endian
375
value containing the size of the data, followed by the data. The
376
entire message must fit in a single datagram.
377
 
378
Examples:
379
Write to fd 4, 256 bytes of data:
380
 
381
0xBEEF 0x00 0x22 0x04 0x00 0x01 ...data...
382
 
383
The server replies with the standard header, followed by the return
384
code, and the number of bytes actually written. For example:
385
 
386
0xBEEF 0x00 0x22 0x00 0x00 0x01 - Successful write of 256 bytes
387
0xBEEF 0x00 0x22 0x06 - Failed write, error is "bad file descriptor"
388
 
389
CLOSE - Closes a file - Command 0x23
390
------------------------------------
391
Closes an open file. Consists of the standard header, followed by
392
the file descriptor. Example:
393
 
394
0xBEEF 0x00 0x23 0x04 - Close file descriptor 4
395
 
396
The server replies with the standard header followed by the return
397
code:
398
 
399
0xBEEF 0x00 0x23 0x00 - File closed.
400
0xBEEF 0x00 0x23 0x06 - Operation failed with EBADF, "bad file descriptor"
401
 
402 197 winston
 
403
STAT - Get information on a file - Command 0x24
404
-----------------------------------------------
405
Reads the file's information, such as size, datestamp etc. The TNFS
406
stat contains less data than the POSIX stat - information that is unlikely
407
to be of use to 8 bit systems are omitted.
408
The request consists of the standard header, followed by the full path
409
of the file to stat, terminated by a NULL. Example:
410
 
411
0xBEEF 0x00 0x24 /foo/bar/baz.txt 0x00
412
 
413
The server replies with the standard header, followed by the return code.
414
On success, the file information follows this. Stat information is returned
415 291 winston
in this order. Not all values are used by all servers. At least file
416
mode and size must be set to a valid value (many programs depend on these).
417 197 winston
 
418
File mode       - 2 bytes: file permissions - little endian byte order
419
uid             - 2 bytes: Numeric UID of owner
420
gid             - 2 bytes: Numeric GID of owner
421
size            - 4 bytes: Unsigned 32 bit little endian size of file in bytes
422
atime           - 4 bytes: Access time in seconds since the epoch, little end.
423
mtime           - 4 bytes: Modification time in seconds since the epoch,
424
                           little endian
425
ctime           - 4 bytes: Time of last status change, as above.
426
uidstring       - 0 or more bytes: Null terminated user id string
427
gidstring       - 0 or more bytes: Null terminated group id string
428
 
429
Fields that don't apply to the server in question should be left as 0x00.
430
The ┬┤mtime' field and 'size' fields are unsigned 32 bit integers.
431
The uidstring and gidstring are helper fields so the client doesn't have
432
to then ask the server for the string representing the uid and gid.
433
 
434
File mode flags will be most useful for code that is showing a directory
435
listing, and for programs that need to find out what kind of file (regular
436
file or directory, etc) a particular file may be. They follow the POSIX
437
convention which is:
438
 
439
Flags           Octal representation
440
S_IFMT          0170000         Bitmask for the file type bitfields
441
S_IFSOCK        0140000         Is a socket
442
S_IFLNK         0120000         Is a symlink
443
S_IFREG         0100000         Is a regular file
444
S_IFBLK         0060000         block device
445
S_IFDIR         0040000         Directory
446
S_IFCHR         0020000         Character device
447
S_IFIFO         0010000         FIFO
448
S_ISUID         0004000         set UID bit
449
S_ISGID         0002000         set group ID bit
450
S_ISVTX         0001000         sticky bit
451
S_IRWXU         00700           Mask for file owner permissions
452
S_IRUSR         00400           owner has read permission
453
S_IWUSR         00200           owner has write permission
454
S_IXUSR         00100           owner has execute permission
455
S_IRGRP         00040           group has read permission
456
S_IWGRP         00020           group has write permission
457
S_IXGRP         00010           group has execute permission
458
S_IROTH         00004           others have read permission
459
S_IWOTH         00002           others have write permission
460
S_IXOTH         00001           others have execute permission
461
 
462
Most of these won't be of much interest to an 8 bit client, but the
463
read/write/execute permissions can be used for a client to determine whether
464
to bother even trying to open a remote file, or to automatically execute
465
certain types of files etc. (Further file metadata such as load and execution
466
addresses are platform specific and should go into a header of the file
467
in question). Note the "trivial" bit in TNFS means that the client is
468
unlikely to do anything special with a FIFO, so writing to a file of that
469
type is likely to have effects on the server, and not the client! It's also
470
worth noting that the server is responsible for enforcing read and write
471
permissions (although the permission bits can help the client work out
472
whether it should bother to send a request).
473
 
474 198 winston
LSEEK - Seeks to a new position in a file - Command 0x25
475
--------------------------------------------------------
476
Seeks to an absolute position in a file, or a relative offset in a file,
477
or to the end of a file.
478
The request consists of the header, followed by the file descriptor,
479
followed by the seek type (SEEK_SET, SEEK_CUR or SEEK_END), followed
480
by the position to seek to. The seek position is a signed 32 bit integer,
481
little endian. (2GB file sizes should be more than enough for 8 bit
482
systems!)
483
 
484
The seek types are defined as follows:
485
0x00            SEEK_SET - Go to an absolute position in the file
486
0x01            SEEK_CUR - Go to a relative offset from the current position
487
0x02            SEEK_END - Seek to EOF
488
 
489
Example:
490
 
491
File descriptor is 4, type is SEEK_SET, and position is 0xDEADBEEF:
492
0xBEEF 0x00 0x25 0x04 0x00 0xEF 0xBE 0xAD 0xDE
493
 
494
Note that clients that buffer reads for single-byte reads will have
495
to make a calculation to implement SEEK_CUR correctly since the server's
496
file pointer will be wherever the last read block made it end up.
497
 
498
UNLINK - Unlinks (deletes) a file - Command 0x26
499
------------------------------------------------
500
Removes the specified file. The request consists of the header then
501
the null terminated full path to the file. The reply consists of the
502
header and the return code.
503
 
504
Example:
505
Unlink file "/foo/bar/baz.bas"
506
0xBEEF 0x00 0x26 /foo/bar/baz.bas 0x00
507
 
508
CHMOD - Changes permissions on a file - Command 0x27
509
----------------------------------------------------
510
Changes file permissions on the specified file, using POSIX permissions
511
semantics. Not all permissions may be supported by all servers - most 8
512
bit systems, for example, may only support removing the write bit.
513
A server running on something Unixish will support everything.
514
The request consists of the header, followed by the 16 bit file mode,
515
followed by the null terminated filename. Filemode is sent as a little
516
endian value. See the Unix manpage for chmod(2) for further information.
517
 
518
File modes are as defined by POSIX. The POSIX definitions are as follows:
519
 
520
Flag      Octal Description
521
S_ISUID   04000 set user ID on execution
522
S_ISGID   02000 set group ID on execution
523
S_ISVTX   01000 sticky bit
524
S_IRUSR   00400 read by owner
525
S_IWUSR   00200 write by owner
526
S_IXUSR   00100 execute/search by owner
527
S_IRGRP   00040 read by group
528
S_IWGRP   00020 write by group
529
S_IXGRP   00010 execute/search by group
530
S_IROTH   00004 read by others
531
S_IWOTH   00002 write by others
532
S_IXOTH   00001 execute/search by others
533
 
534
Example: Set permissions to 755 on /foo/bar/baz.bas:
535
0xBEEF 0x00 0x27 0xED 0x01 /foo/bar/baz.bas
536
 
537
The reply is the standard header plus the return code of the chmod operation.
538
 
539 288 winston
RENAME - Moves a file within a filesystem - Command 0x28
540
--------------------------------------------------------
541
Renames a file (or moves a file within a filesystem - it must be possible
542
to move a file to a different directory within the same FS on the
543
server using this command).
544
The request consists of the header, followed by the null terminated
545
source path, and the null terminated destination path.
546
 
547
Example: Move file "foo.txt" to "bar.txt"
548
0xBEEF 0x00 0x28 foo.txt 0x00 bar.txt 0x00
549
 
550 199 winston
DEVICE OPERATIONS
551
=================
552
These operations get information about the device that is mounted.
553
 
554
SIZE - Requests the size of the mounted filesystem - Command 0x30
555
-----------------------------------------------------------------
556
Finds the size, in kilobytes, of the filesystem that is currently mounted.
557
The request consists of a standard header and nothing more.
558
 
559
Example:
560
0xBEEF 0x00 0x30
561
 
562
The reply is the standard header, followed by the return code, followed
563
by a 32 bit little endian integer which is the size of the filesystem
564
in kilobytes, for example:
565
 
566
0xBEEF 0x00 0x30 0x00 0xD0 0x02 0x00 0x00 - Filesystem is 720kbytes
567
0xBEEF 0x00 0x30 0xFF - Request failed with error code 0xFF
568
 
569
FREE - Requests the amount of free space on the filesystem - Command 0x31
570
-------------------------------------------------------------------------
571
Finds the size, in kilobytes, of the free space remaining on the mounted
572
filesystem. The request consists of the standard header and nothing more.
573
 
574
Example:
575
0xBEEF 0x00 0x31
576
 
577
The reply is as for SIZE - the standard header, return code, and little
578
endian integer for the free space in kilobytes, for example:
579
 
580
0xBEEF 0x00 0x31 0x00 0x64 0x00 0x00 0x00 - There is 64K free.
581
0xBEEF 0x00 0x31 0x1F - Request failed with error 0x1F
582
 
583 182 winston
LIST OF VALID RETURN CODES
584
==========================
585
Note not all servers may return all codes. For example, a server on a machine
586
that doesn't have named pipes will never return ESPIPE.
587
 
588
ID      POSIX equiv     Description
589
0x00                    Success
590
0x01    EPERM           Operation not permitted
591
0x02    ENOENT          No such file or directory
592
0x03    EIO             I/O error
593
0x04    ENXIO           No such device or address
594
0x05    E2BIG           Argument list too long
595
0x06    EBADF           Bad file number
596
0x07    EAGAIN          Try again
597
0x08    ENOMEM          Out of memory
598
0x09    EACCES          Permission denied
599
0x0A    EBUSY           Device or resource busy
600
0x0B    EEXIST          File exists
601
0x0C    ENOTDIR         Is not a directory
602
0x0D    EISDIR          Is a directory
603
0x0E    EINVAL          Invalid argument
604
0x0F    ENFILE          File table overflow
605
0x10    EMFILE          Too many open files
606
0x11    EFBIG           File too large
607
0x12    ENOSPC          No space left on device
608
0x13    ESPIPE          Attempt to seek on a FIFO or pipe
609
0x14    EROFS           Read only filesystem
610
0x15    ENAMETOOLONG    Filename too long
611
0x16    ENOSYS          Function not implemented
612
0x17    ENOTEMPTY       Directory not empty
613
0x18    ELOOP           Too many symbolic links encountered
614
0x19    ENODATA         No data available
615
0x1A    ENOSTR          Out of streams resources
616
0x1B    EPROTO          Protocol error
617
0x1C    EBADFD          File descriptor in bad state
618
0x1D    EUSERS          Too many users
619
0x1E    ENOBUFS         No buffer space available
620
0x1F    EALREADY        Operation already in progress
621
0x20    ESTALE          Stale TNFS handle
622 185 winston
0x21    EOF             End of file
623 182 winston
0xFF                    Invalid TNFS handle
624