Subversion Repositories Spectranet

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

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