A number of packets are defined to give an application some control over a file system: ACTION_DIE 5 <sendpkt only> RES1: BOOL DOSTRUE As its name implies, the ACTION_DIE packet tells a handler to quit. All new handlers are expected to implement this packet. Because of outstanding locks and the fact that the handler address is returned by the DeviceProc() routine, it is unlikely that the handler can disappear completely, but instead will have to release as many resources as possible and simply return an error on all packets sent to it. In the future, the system may be able to determine if there are any outstanding DeviceProc() references to a handler, and therefore make it is safe to shut down completely. ACTION_FLUSH 27 <sendpkt only> RES1: BOOL DOSTRUE This action causes the file system to flush out all buffers to disk before returning this packet. If any writes are pending, they must be processed before responding to this packet. This packet allows an application to make sure that the data that is supposed to be on the disk is actually written to the disk instead of waiting in a buffer. ACTION_MORE_CACHE 18 AddBuffers(...) in 2.0 ARG1: LONG Number of buffers to add RES1: BOOL DOSTRUE (-1L) RES2: LONG New total number of buffers This action allows an application to change the number of internal buffers used by the file system for caching. Note that a positive number increases the number of buffers while a negative number decreases the number of buffers. In all cases, the number of current buffers should be returned in RES2. This allows an application to inquire the number of buffers by sending in a value of 0 (resulting in no change). Note that the OFS and FFS in 1.3 do not accept a negative number of buffers. Note that there is a bug in the ROM file system in both Release 2.04 and Release 3.0 that jumbles its return values for this packet. The file system erroneously returns the new number of buffers in RES1 instead of RES2 (it returns a failure code in RES2). To work around this bug when using this packet, test RES1 to see if it is DOSTRUE (-1L). If it is, look at RES2 for the number of buffers, otherwise RES1 should contain the new total number of buffers. ACTION_INHIBIT 31 Inhibit(...) in 2.0 ARG1: BOOL DOSTRUE = inhibit, DOSFALSE = uninhibit RES1: BOOL Success/failure (DOSTRUE/DOSFALSE) This action is probably one of the most dangerous that a file system has to handle. When inhibited (ARG1 = DOSTRUE), the file system must not access any underlying media and return an error code on all attempts to access the device. Once uninhibited (ARG1 = DOSFALSE), the file system must assume that the medium has been changed. The file system must flush the buffers before the ACTION_INHIBIT , popping up a requester demanding that the user put back the current disk, if necessary. The handler may choose to reject an inhibit request if any objects are open for writing. Although it's not required, a handler should nest inhibits. Prior to 2.0, the system handlers did not keep a nesting count and were subject to some obscure race conditions. The 2.0 ROM filing system introduced a nesting count. ACTION_WRITE_PROTECT 1023 <sendpkt only> ARG1: BOOL DOSTRUE/DOSFALSE (write protect/un-write protect) ARG2: LONG 32 Bit pass key RES1: BOOL DOSTRUE/DOSFALSE This is a new packet defined for the Fast File System. This packet allows an application to change the write protect flag of a disk (if possible - applications cannot write to floppies that have their write-protect tabs set). This packet is primarily intended to allow write-protecting non-removable media such as hard disks. The value in ARG1 toggles the write status. The 32-bit passkey allows a program to prevent other programs from unwrite-protecting a disk. To unlock a disk, ARG2 must match the passkey of the packet that locked the disk, unless the disk was locked with a passkey of 0. In this case, no passkey is necessary to unlock the disk. ACTION_IS_FILESYSTEM 1027 IsFileSystem(devname) RES1: BOOL Success/Failure (DOSTRUE/DOSFALSE) RES2: CODE Failure code if RES1 is DOSFALSE Through this function, a handler can indicates whether or not it is a file system (whether or not it can support separate files for storing information). Programs will assume a handler can create multiple, distinct files through calls to Open() if the handler returns this packet with a DOSTRUE value. A handler does not need to support directories and subdirectories in order to qualify as a file system. It does have to support the Examine()/ExNext() calls. Note that the AmigaDOS routine IsFileSystem() will attempt to use Lock(":",SHARED_ACCESS) if this packet returns ERROR_ACTION_NOT_KNOWN.
[Back to Amiga Developer Docs]