SFS supports filenames up to 100 characters (note: only 95 via Workbench—the remaining five are reserved for ".info" extensions) characters. The newer versions of PFS3 also support longer filenames, but you have to tell PFS3 that you want to do that. The command "setfnsize" that comes with PFS3 enables you to do that. For example, if you type:

  SetFnSize volume: 100

in a Shell window, filenames are set to allow up to 100 characters, and the change is permanent. It wouldn't make sense if the filesystem truncated filenames again just because it forgot to save this option. You can't lower the maximum filename length as it could force PFS3 to truncate filenames, and the author wisely decided against supporting this.

Maximum filename lengths for the popular filesystems are as follows:

• AmigaDOS (dos.library): 102, plus 5 reserved for ".info" files
• Workbench/Fast File System (FFS): 25, plus 5 reserved for ".info" files
• Smart File System (SFS): 95, plus 5 reserved for ".info" files
• Professional File System (PFS): 102, plus 5 reserved for ".info" files (PFS has a minimum of 31 characters)
• Ami-File Safe (AFS): diskname length - 32, filename length - 96, comment length - 80

The maximum filename length that the filesystem supports is different from the setting in Workbench. The Workbench setting only dictates the length of filenames that it is able to handle; e.g. when displaying or copying files. You can still have longer filenames on your SFS or PFS-based hard drive. When Workbench shows truncated filenames, it doesn't mean that they are actually truncated on the hard drive, but rather that you forgot to make the Workbench MAXNAMELENGTH option permanent.

Remember that when you use WBCtrl to invoke this setting you have to put it in the User-startup, and if you use TweakWB you have to put it in the WBStartup drawer in order for this function to be called each time you reboot. [Martin Steigerwald]

Even if you use a filesystem that could theoretically support longer filenames, they will always be truncated to 107 characters by dos.library. Some applications have hardcoded limits for filenames and do not support the maximum filename length that AmigaDOS—but not FFS—supports. Amiga Inc. will not patch those applications; it is the responsibility of the application's developer to change it. [Martin Steigerwald, Etienne Vogt, and Harry Sintonen]

About installing/updating the filesystem:

1st: Accidentally overwriting a different filesystem (PFS/SFS) with FFS will destroy your data. A backup is a good idea in general.

2nd: Don't fiddle around with the block size or filesystem type (normal/dircache) when working on an existing, installed partition which contains your data.

3rd: Keep your mouse pointer away from other buttons if you don't know their function! Follow only the steps below. If you're unsure, make use of the CANCEL gadget and ask someone who knows what to do!

You can control all manner of HDD device drivers with HDToolBox, not just "scsi.device". Enter "ASKDEVICE=YES" in HDToolBox' tooltypes, and then...

• Start HDToolbox and select the device that controls your HDD, then the drive in question.
• Click the "Partition drive" gadget. In the lower right corner is a section labeled "File System", below it a line that shows the filesystem in use on the selected partition.
• Click the "Add/Update" gadget. From the listview that is now shown, select the filesystem you want to update (it should really read "FastFileSystem" and nothing else!)
• Click the "Update File System..." gadget. From the filerequester, select the new FFS ("L:FastFileSystem").
• Click the "OK" gadget, and you'll be returned to the partition drive window.
• Click on the "Save" button, then Exit HDToolBox.

You're now done. To make the change take effect, reboot your Amiga.

With these steps you copy the filesystem into the RDB. It is not just a link or pointer to the filesystem that was installed with the OS 3.5 installer. [Heinz Wrobel]

The SCSIConfig vs. HDWrench [and thus HDToolbox] incompatibility has been fixed in Boing Bag 2a, as Joanne Dow explains:

"Until I got some good debug files via Juergen and Martin, RDPrepX and hdwrench.library would fail big time on some SCSIConfiged disks. It was an interesting mystery. With version 44.111 that was fixed. It stemmed from an ambiguity in the RDB specifications where the use of a specific term was not spelled out in detail. (And it MAY be that nobody has ever used the complementing term, RDBHi, correctly. Mostly people ignore it and set it to 16. But then, RDBLow and RDBHi are not really sensible terms to have in the RDSK block, perhaps. At least RDBHi isn't all that useful.)

The RDBLow term as used in RDPrepX and "most" configuration tools that worked nicely was a self reference to the RDSK block itself. SCSIConfig merely set it to zero regardless of the RDSK block. When the data is on disk it does not make any difference. However, when you suck the data up into a series of linked list memory blocks it becomes very important that it match the RDSK block's ID. The easy way to "calculate" memory locations is relative to the desired block number minus the RDSK block number. As changed hdwrench now forces that value when data is loaded off a disk. Then it can "renumber" and align the blocks to compress out RDB blocks that may have been removed, such as LSEG blocks for a no-longer used filesystem or the like. Call it "garbage collection".

So for the most part any hdwrench.library above 44.111 should work with a SCSIConfig disk and vice versa, I believe."

Martin Steigerwald notes that:

"You should never mix SCSIConfig and HDToolBox when it comes to editing/preparing one and the same harddisk. Never, never, never. Stick with the program you initially used to prepare your HDD.

SCSIConfig has a different geometry calculation than HDToolbox; even if you only enable the "synchron" flag in SCSIConfig, it actually does write its own new geometry calculations to the RDB, causing a big mess-up when you add new partitions to the drive; you get overlapping partitions!

Never ever combine the usage of these two programs for the same drive. As far as I know this is valid for all versions of SCSIConfig as of 4-Feb-2000."

"NSD" itself is a guideline on how an exec device driver should be designed, so that its capabilities can be identified. "NSD" is a textfile with instructions for developers—not a program. The idea is a unified exec device system (exec device means eg. "serial.device" as opposed to "SER:",which is a DOS device).

"NSDPatch" however is a program that can make old devices (that were created before the definition of NSD) look NSD compliant. In addition, it fixes some bugs and broken devices. It can also add basic 64-bit functionality for trackdisk-like devices to break the 4GB barrier of old HDD device drivers.

NSDPatch, as Heinz Wrobel puts it, "emulates" NSD on old devices by adding a header on top of them. In "NSDPatch.cfg" (which is installed to DEVS: by the OS 3.5 installer), the definitions (that would be part of a New Style Device anyway) are written down. Don't mess with the config file if you don't really know what you're doing.

"NSDPatch" is integrated into SetPatch as of OS 3.5. You do not need to install it separately.

For more information, you can download the original NSDPatch archive, it comes with a good .guide, and the original NSD definitions from the website of Amiga Inc. (currently the files section is not available).

When you're doing a cold boot (you switch on your Amiga), you have neither the NSDPatch 64-bit functionality, nor do you have the "AmigaOS ROM update" activated yet.

Don't get confused—cold boot only!

The following statement is valid for all Amiga models that have an internal "SCSI" connector, be it a real scsi.device (A3000/T, A4000T) or the pseudo IDE_scsi.device (A600, A1200, A4000):

Your boot partition must be in the lower 4GB range! Even if you have FFS v45 or later installed in the RDB of the HDD. FFS v45 alone can not use its 64-bit commands on the old v40 scsi.device!

Furthermore, the v40 IDE_scsi.device has an internal unchangeable limit of 8GB, which means:

If you're using a filesystem that has "direct scsi" or "TD64" support (e.g. PFS, SFS) on an A600/A1200/A4000, your boot partition must be within the lower 8GB.

[Colin Wenzel/question, Heinz Wrobel/answers]

An NSD-patched scsi.device has simple 64-bit functionality. It's an emulation via HD_SCSICMD; nothing more. The complete, working stuff with internal control, retries, error handling etc. is only available via the "AmigaOS ROM update" to scsi.device v43 that is applied via SetPatch.

And don't forget: if you have an A600/A1200/A4000, you're still stuck with the internal 8GB limit of the v40 IDE_scsi.device. You can use a HDD with no more than 8GB if you apply the NSD patch to the internal ROM IDE_scsi.device v40—8GB, nothing more.

Filesystems like PFS and SFS which have e.g. a "direct scsi" version must use the IDE_scsi.device as well, so the 8GB limit applies here as well (the docs of e.g. PFS are a bit vague on this topic).

You can not patch the internal 8GB limit of the old IDE_scsi.device with NSDPatch, nor can you avoid it with a third party filesystem's "direct scsi" version.

If you want to use a HDD larger than 8GB on the internal IDE_scsi connector of the A600/A1200/A4000, regardless of the filesystem, you must use the IDE_scsi.device from the ROM update, or completely replace the driver with a TD64/NSD-compliant one, e.g. with IDE-Fix (thanks to Kolbjørn Barmen) [Heinz Wrobel].

The new HDToolBox does not use NSD for device recognition. A device needs to be opened to recognize its type. One of its unit's has to be locked, additionally. If HDToolBox would do this for all devices present in the system, it would require too many resources, and locking a unit can be problematic—just think of printer.device. Furthermore, you might have experienced crashing non-NSD devices when you try the "CHECKALL" option of NSDQuery.

Therefore, HDToolBox has an internal, hard-coded exclusion list of the devices which are not to be shown in the list. Alas, devices which aren't in the exclusion list will be shown—but better this than the other way around. [Jochen Becher]

The correct patch entries (as shown below) are included in Boing Bag 2a.

   # DKB WildFire
   DEVICE wildfirescsi.device DEVICETYPE NSDEVTYPE_TRACKDISK ***
      COMMANDS 2-5,9,11-15,20-22,28 VERSION 1 REVISION 1

   # DKB FerretROM V1.28
   DEVICE dkbscsi.device DEVICETYPE NSDEVTYPE_TRACKDISK COMMANDS ***
      2-5,9,11-15,20-22,28,$8002-$8005,$8009,$800b-$800f,$8014-$8016,***
      $801c VERSION 1 REVISION 28

Remove the "***" symbols and directly append the lines so they are in one single line. They are only split here for readability.

Larger paritions can be made. However, if you have to validate a partition larger than 2GB, you may experience crashes due to out of memory conditions during validation. Hence it is not a good idea to create very large partitions unless you have a major boatload of RAM available; the number is strictly approximate.

Experience suggests a 4GB partition is too big for an 18MB Amiga 3000 (I've read messages from owners of such systems complaining about it). Personal experience with a 1GB partition indicate it was a bit too big for a 9MB Amiga 2000. It depends on partition size, directory structure complexity, number of files, etc. Results will vary greatly on every system. [Kulwant Bhogal, Joan Dow]

# CardDisk (Amiga 1200/Amiga 600 PCMCIA slot)
DEVICE carddisk.device  DEVICETYPE NSDEVTYPE_TRACKDISK COMMANDS 2-5,9,11-15,20-22

Under OS 3.5, Workbench writes files in a different manner (different to OS 3.0, 3.1, or 3.9 Workbench) which leads to trouble if your hard drive controller doesn't correctly support reselection (which are mostly Phase 5 controllers). Switch off reselection for the appropriate unit and everything should work fine.

[Wolfgang Hosemann]