File type modifiers

The file type modifiers are:

Modifier Description Comments


File is always writable on client



Execute bit set on client

Used for executable files, such as a shell script.


RCS keyword expansion

Expands RCS (Revision Control System) keywords.

RCS keywords are case-sensitive.

When using keywords in files, a colon after the keyword (for instance, $Id:$) is optional.

UTC keywords are better suited to describe events in globally distributed installations.

Supported keywords are as follows:

  • $Id$
  • $Header$
  • $Date$ Date of submission
  • $DateUTC$ Date of submission in UTC time zone
  • $DateTime$ Date and time of submission
  • $DateTimeUTC$ Date and time of submission in UTC time zone.
  • $DateTimeTZ$ Date and time of submission in the server’s time zone, but including the actual time zone in the result.
  • $Change$
  • $File$
  • $Revision$
  • $Author$
+ko RCS keyword expansion of ID and Header only  


Exclusive open (locking)

If set, only one user at a time will be able to open a file for editing.

Useful for binary file types (such as graphics) where merging of changes from multiple authors is meaningless.


Perforce stores the full compressed version of each file revision

Default storage mechanism for binary files and newly-added text, unicode, and utf16 files larger than 10MB.


Perforce stores deltas in RCS format

Prior to 2022.1, RCS format was the default storage mechanism for text files. Since 2022.1 the lbr.autocompress configurable defaults to 1, and all new files are stored as compressed. To override this default and make a specific file store its deltas in RCS format, specify the +D filetype modifier. See Examples for p4 add.


Perforce stores full file per revision, uncompressed

Useful for large binaries, or for long ASCII files that are not read by users as text, such as PostScript files.

In a depot of type graph, binary+F is valid for Git Large File Storage (LFS).


Only the head revision is stored

Older revisions are purged from the depot upon submission of new revisions. Useful for executable or .obj files.


Only the most recent n revisions are stored, where n is a number from 1 to 10, or 16, 32, 64, 128, 256, or 512.

Older revisions are purged from the depot upon submission of more than n new revisions, or if you change an existing +Sn file’s n to a number less than its current value. Earlier revisions unaffected. For details, see Usage Notes.


Preserve original modtime

The file’s timestamp on the local filesystem is preserved upon submission and restored upon sync. Useful for third-party DLLs in Windows environments.


Archive trigger required

The Perforce service runs an archive trigger to access the file. See Triggering to affect archiving in the Helix Core Server Administrator Guide.

Overriding file type with the -t option

A file’s type is normally preserved between revisions, but can be overridden or changed with the -t option during add, edit, or reopen operations:

  • p4 add -t filetype filespec adds the files as the specified type.
  • p4 edit -t filetype filespec opens the file for edit as the specified type. The file’s type is changed to the specified filetype only after it is submitted to the depot.
  • p4 reopen -t filetype filespec changes the type of a file already open for add or edit.

The filetype argument is specified as [basetype] +modifiers. For example, to change's type to executable text with RCS keyword expansion, use p4 edit -t text+kx

Partial filetypes are also acceptable. For example, to change an existing text file to text+x, use p4 reopen -t +x Most partial filetype modifiers are added to the filetype, but the storage modifiers (+C, +D, and +F) replace the file’s storage method. To remove a modifier, you must specify the full filetype.