Browse Prior Art Database

DosGetLastChangedDateTime Program

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

Publishing Venue

IBM

Related People

Weber, O: AUTHOR

Abstract

This article describes a consistent mechanism which enables OS/2* application programs to retrieve the date and time that an OS/2 object was last changed. Currently, the only methods for retrieving the date and time of an OS/2 object's last change require that the user know several things about the object, including the 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 last changed date and time.

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

DosGetLastChangedDateTime Program

      This article describes a consistent mechanism which
enables OS/2* application programs to retrieve the date and time that
an OS/2 object was last changed.  Currently, the only methods for
retrieving the date and time of an OS/2 object's last change require
that the user know several things about the object, including the
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 last changed
date and time.  There needs to be a single and consistent API
(Application Programming Interface) to determine the date and time of
the last change 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 last change date and time
of the file in the "fstatus" structure.  Then, a DosClose call can be
issued 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 last change
date and time of the file in the "filefindbuf" structure, and the
DosClose should not be issued to close the file since it was
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.  H...