Enables/disables the recording of the last access date of a file.
The ACCDATE statement is only valid in Config.sys.


ACCDATE=drive1+|- [drive2+|-] ...
+ Enables last access date recording
- Disables last access date recording


  1. Apart from keeping track of exactly where a file is located on disk, the FAT (File Allocation Table) also stores such details as file size, and the date/time the file was created, last modified, and last accessed. Most, if not all(?), programs used to archive files or compile program installation files include the "last modified" date with each file but not record either the creation or last access dates. Thus:
    File Creation Date
    This is the date the file was created on the current machine. For program files this will typically be the date the program was last installed - i.e. expanded from the packed/zipped/setup files. For data files this will be the date they were first saved (or retrieved from an archive).
    The only way I know to display the "file creation date" is via Windows Explorer using the File|Properties - I am not aware of any Dos command that will display it.
    File Last Modified Date
    This is the date the file was last modified (on any machine). This is the generally accepted file's datestamp.
    Last Access Date
    The only cases where I have found "Last Access Date" to be shown are with the DIR /V command in Dos and under a file's "Properties" tab in Windows Explorer in Win95/8.

    With Windows Explorer, unfortunately, the very act of checking a file's "last access date" is taken as an access and so is always the current date - whether hard or floppy drive, normal or safe mode, and whatever the settings used with ACCDATE in Config.sys.

    With DIR /V the dates given make more sense but the "last access date" for directories is always the same as the "creation date".

    Some utility programs likely use this information when deciding if a file should be classified as "seldom used" and a candidate for archiving. Tom Gutman suggests:

    "I think that the main user of the last accessed date is DriveSpace 3. It has several levels of compression available, and when you use compression agent to change compression modes, some options depend on when a file was last accessed. This is for the high pack option (which apparently takes more time to decompress, as well as to compress) and to use that option only for files that have not been accessed in a while".

  2. In response to a query on Usenet, Charles Dye offered the following:
    INT 21 .AX=5704 Get last access date and time
    INT 21 .AX=5705 Set last access date and time
    INT 21 .AX=5706 Get creation date and time
    INT 21 .AX=5707 Set creation date and time

    The values go in previously unused (officially unused!) bytes in the short-name directory entry. Which means that recording this info could screw up other operating systems which use the "unused" bytes for other functions. DR DOS's password scheme springs to mind.

  3. Other Usenet postings going back to '95 suggest that using ACCDATE drive- will reduce some disk activity and hence could speed up system operation a smidgen.

  4. I am finding it kind of tricky to get a handle on exactly how ACCDATE works and how it might be used. According to the notes in the Config.txt file on the Win95 CD (also available as MS Knowledgebase Q135481) about Win95 Config.sys commands:
    "For each hard disk, specifies whether to record the date that files are last accessed. Last access dates are turned off for all drives when your computer is started in safe mode, and are not maintained for floppy disks by default."
    and this is supplemented by article Q182465 which says that problems have been found with ACCDATE and that:
    "When you edit the Config.sys file to include an ACCDATE command so that the last accessed date for files is not updated, files may still be updated with the current date when you make changes."

    I rather get the impression that the business of setting and retrieving a file's last access date was a minor routine that a programmer was playing with before being called off to more pressing things. As it stands, I can see no useful purpose for the statement and, indeed, it seems to be pretty well non functional.

    If I'm missing something here, I'd be most grateful for advice on this!

Thanks to Tom Gutman for pointing out the significance of the various dates and to Charles Dye for posting the interrupt information.
If you should have any comments or suggestions,
please contact: Bob Watson
This page last revised:
June 2, 2000.