Cadzow 2000 File System Support
Cadzow 2000 is a fully native 32-bit Windows application and supports most modern file system features. This article discusses recommendations and issues.
Cadzow 2000 supports FAT16, FAT32 and NTFS volumes under Windows 9x, NT4, 2000 and above.
However, NTFS volumes, for both the storage of data and storage of programs and operating systems, are recommended, due to their reliability, fault-tolerance and increased capacity.
MS-DOS and 16-bit Windows applications can exist on NTFS volumes (as long as you do not disable 8.3 filename generation), so you do not need to maintain FAT volumes for compatibility with older programs. FAT16 and FAT32 volumes can be converted to NTFS volumes without data loss. Consult your IT provider.
BitLocker-encrypted volumes are supported.
When using .MDB databases, non-Microsoft Windows storage volumes/file servers/network attached storage (NAS) are not supported, even if they are using FAT or NTFS volumes. Some examples of unsupported configurations include: Linux-based servers using SAMBA to provide Microsoft networking functions, Home/SOHO or enterprise-grade NAS devices.
When using Microsoft SQL Server, any storage technology supported by Microsoft for use with SQL Server is supported.
Windows 9x supports DriveSpace compression (which allows compressed volumes) and Windows NT/2000 and above support NTFS compression (which allows compressed files, folders or volumes). Cadzow 2000 does not disallow compression, which is to say the use of compression is invisible to Cadzow 2000 and compression is highly reliable in ideal conditions. However, the use of compression is to be avoided when using any sort of critical business data, in particular databases, including Cadzow 2000. There are two main reasons for this:
- Reliability: Compression makes data recovery much harder, if not impossible, in the event of file system corruption. Even a tiny amount of corruption, such as a single bad sector, could be completely harmless on a uncompressed file/volume, but devastating on a compressed file/volume; and
- Performance: Database systems tend to bypass normal file system functions when committing data to disk, which allows them to be more efficient. Compression complicates the process because it is so much harder to determine where on the disk the information is to be written, and the process becomes much slower.
Microsoft does not support SQL Server databases or other database types on compressed volumes and recommends avoiding it on systems with a lot of write activity.
For this discussion there are three types of filename conventions:
- Short MS-DOS 8.3 names, such as C:\DATA\LETTER.DOC;
- Filenames which use long names and possibly UNC paths, such as \\SERVER\DATA\Documents\LetterToEmployees.doc; and
- Filenames which use long names and UNC paths and spaces, such as \\SERVER\C$\Documents and Settings\Administrator\Local Settings\Application Data\Microsoft\Media Player\CurrentDatabase_59R.wmdb.
In addition, a fully qualified short filename may be at most about 76 characters whereas a fully qualified long filename can be several hundred characters.
Cadzow 2000 supports the latter style of long filename in all places with the following exceptions:
- When using a JET datasource (.MDB), the path and filename (typically <root>\CADZOW\SUCCESS7\CLIENTS\xxx\yyy.MDB) may not contain spaces;
- The workgroup database (.MDW) path and filename (typically <root>\CADZOW\SUCCESS7\CLIENTS\CADZPROG.MDW) may not contain spaces;
- The Markers directory (typically <root>\CADZOW\SUCCESS7\MARKERS) may not contain spaces;
- On Windows NT 4.0, the TEMP directory must be resolvable to a short 8.3 style path.
In normal circumstances the TEMP directory is automatically specified in 8.3 notation by Windows, even if the actual path is long. For example, the default TEMP directory in Windows 2000 and above is C:\Documents and Settings\User\Local Settings\Temp, whereas TEMP will be defined as C:\DOCUME~1\USER\LOCALS~1\TEMP. This is because 16-bit, legacy and many scripted applications rely on a relatively short path without spaces. However, there are three instances where this will not occur: (1) when using a particular version of the Netware client which incorrectly sets TEMP to a long path, (2) where the TEMP directory has been manually specified and (3) on an NTFS volume where 8.3 filename generation has been disabled. Due to scripting limitations in Windows NT 4.0, Cadzow 2000 requires that the TEMP directory be in 8.3 format. In the case of (1) and (2) this is no problem as a long path can be converted to a short path but in the case of (3) no 8.3 equivalent exists. Therefore Cadzow 2000 does not support long TEMP directories located on NTFS volumes with 8.3 filenames disabled under Windows NT 4.0. If you have a volume of this type, manually set the TEMP variable to a short location such as C:\TEMP.
However, while long names and UNC paths are supported, short names with mapped drives are recommended for performance reasons. (1, 2)
Distributed File System (DFS)
Cadzow 2000 fully supports data files etc specified with DFS, subject to the limitations discussed in Long Filenames above.
In addition, Cadzow 2000 attempts to report low disk space conditions on startup by checking the volume where the data is stored and the TEMP location. However, since the DFS root can be on a different volume than the target directory, Cadzow 2000 will not be able to determine the space available. Therefore when storing data files on DFS paths, ensure there is sufficient free space for expansion.
USB Drives and Other Removable Devices
USB and other removable drives typically appear in Windows as a drive letter such as E:, F: etc. Files may be copied to and from the drive as per normal. However, some models of these drives do not implement a volume label, which causes the 32-bit command-line version of PKZIP (used by the Cadzow 2000 Backup utility) to fail, as it attempts to set a volume label. To work around this problem, backup to drive C: and then copy the file to the device manually using Windows Explorer.