Browse Prior Art Database

DosGetCreationDate Program

IP.com Disclosure Number: IPCOM000122012D
Original Publication Date: 1991-Oct-01
Included in the Prior Art Database: 2005-Apr-04
Document File: 2 page(s) / 66K

Publishing Venue

IBM

Related People

Weber, O: AUTHOR

Abstract

This article describes a consistent mechanism for retrieving the date and time that an object was created. Currently, the only methods for retrieving the date and time of an OS/2* object's creation require that the user know several things about the object, including what type of object it is, and what its status is at the time the request is made. The latter is particularly hazardous, because the object's status can change at any time. Also, as will be demonstrated below, since the application may not know the type and/or status of the object, it does not know where to look for the returned creation date and time. There needs to be a single and consistent API (Application Programming Interface) to determine the date and time of creation for any OS/2 object, regardless of its type or status.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

DosGetCreationDate Program

      This article describes a consistent mechanism for
retrieving the date and time that an object was created.  Currently,
the only methods for retrieving the date and time of an OS/2*
object's creation require that the user know several things about the
object, including what type of object it is, and what its status is
at the time the request is made. The latter is particularly
hazardous, because the object's status can change at any time.  Also,
as will be demonstrated below, since the application may not know the
type and/or status of the object, it does not know where to look for
the returned creation date and time.  There needs to be a single and
consistent API (Application Programming Interface) to determine the
date and time of creation for any OS/2 object, regardless of its type
or status.  If the object is a file, and this file is currently
closed, then the DosOpen API can be used to open the closed file.
Then the DosQFileInfo API can be used to return the creation date and
time of the file in the "fstatus" structure.  Then a DosClose can be
used to close the file.  However, if the object is a file, and this
file happens to already be open, then the DosOpen fails, and a
DosFindFirst API must be issued, which then returns the creation date
and time of the file in the "filefindbuf" structure, and the DosClose
should not be issued to close the file since it was opened from
somewhere else (and in this case, the DosClose would fail anyway
since the handle would be invalid).  In this case, the DosFindClose
would be issued.   However, if the object is a subdirector...