When a file in a bs2fs file system has been modified and cannot be copied back to BS2000 again after processing has been completed, the ufs file concerned is moved to a special bs2fs_lost+found directory in the bs2fs container. If a file which has the same name and stems from an earlier failed attempt to write it back exists there, it is overwritten without an inquiry.
The user can issue the bs2fs_recover command to obtain a list of files which have been relocated in this way and then (for example with a modified name) copy these to BS2000 and/or delete them in the bs2fs container.
Alternatively this task can also be performed by the system administrator in the role of a deputy.
To prevent files which have been relocated to the bs2fs_lost+found area from remaining unnoticed, when the bs2fs container is mounted a message is output on the console which provides information on the user IDs for which files exist in this area. The bs2fs_lost+found area is of course not deleted like the rest of the bs2fs container when the latter is mounted.
The bs2fs_recover command provides a simple way to check whether files of a specific ID exist in the bs2fs_lost+found area. When intensive use is made of the bs2fs file system, it is recommendable to configure an automatic check with this command, e.g. in the logon script ($HOME/.profile or /etc/profile).
In order to get to know how the command works and the mechanisms associated with it, you can use the POSX file /etc/.bs2fsdSimulateCloseError to simulate errors which occur when the bs2fs files are written back. If this file (which requires no content) exists, the ufs file is relocated to the bs2fs_lost+found area irrespective of the success of its being written back to BS2000. If the /etc/.bs2fsdSimulateCloseError file is removed or renamed, the simulation will be canceled.