Integrated File System Secure Delete

This document is obsolete. See Secure Data Erase for the IBM® i  for alternative. 

This document provides information on how to zero out the storage used by an Integrated File System (IFS) file and how to destroy an IFS file.

RMVLNK will remove a link to a file; however, there can be multiple links to a file. An IFS file object is destroyed after the last reference to it is released. Once an object is destroyed, there is no further way for any user to ever look at that storage again, even in SST. However, that does not mean the storage is ever overwritten on the actual disk. Therefore, if someone removed the hard drive with the "destroyed" object on it and had some way of reading the raw data off the disk that did not involve SLIC storage management, they might be able to retrieve the contents of the destroyed file.

There are two APIs that will write a specified number of zeroes to an open file: fclear() and fclear64(). To ensure those zeroes actually get written to disk, you must use fsync().

Then how do you make sure all links are removed? For objects in the root, QOpenSys, and user-defined file systems, one could use the QlgGetAttr() API to retrieve the file ID before unlinking the object, and then use the QlgGetPathFromFileID() API after unlinking the object. If the QlgGetPathFromFileID() API returns ENOENT, the object does not have a path; that is, the object has no links. You can also open the file, unlink the file, and do fstat64() to get the st_nlink field. If st_nlink (or st_nlink32) is 0, then the object has no links. When the file is closed, the object will be destroyed.

So, an example of an algorithm for a secure delete would be as follows: