This implementation of the Archive interface maps to a directory/file structure.
If the directory underlying the FileArchive is created by GlassFish then FileArchive filters its contents so only those files more recent than the creation of the archive itself are visible to consumers.
The main motivation is to hide unwanted "left-over" files from previous deployments that might linger, especially on Windows, after the previous app had been undeployed. (Deployment uses a FileArchive to extract the user's JAR-based archive into the applications directory.) Historically such left-over files arise after GlassFish expands an archive into its exploded form but then some code opens but does not close a file in that exploded directory tree.
An open left-over file can be overwritten-in-place on Windows, and this happens when a caller invokes {@link #putNextEntry(java.lang.String) }to create a new entry (file) inside the archive. But a left-over file that is not in the new app but is still open by GlassFish cannot be deleted or renamed on Windows and so it will remain in the expansion directory. Such left-over files, if not filtered out, can confuse GlassFish and the application. By "stamping" the archive creation date we can filter out such old, left-over files.
To support this feature, when FileArchive creates a directory it stores a marker file there, the contents of which records the creation date/time of the archive. We cannot just use the lastModified value for the top-level directory. Users might legitimately use "touch .reload" in the applications/appName directory to trigger a dynamic reload of the app. If .reload does not already exist then touch creates it, and this would update the lastModified of the directory file.
@author Jerome Dochez
@author Tim Quinn