Helix Core is now P4. Product user interfaces will be updated soon. Learn more >>

P4 CLI Reference | 2025.1

# Usage notes

- The type of an existing file can be determined with `p4 opened` or `p4 files`.
- Delta storage (the default mode with `text` files) is a method whereby only the differences (or deltas) between revisions of files are stored. Full file storage (the default mode with `binary` files) involves the storage of the entire file. The file’s type determines whether full file or delta storage is used. Perforce uses RCS format for delta storage.
- Some of the file types are compressed to `gzip` format for storage in the depot. The compression occurs during the submission process, and decompression happens while syncing. The process is transparent to the user because the client workspace always contains the file as it was submitted.
- Symbolic links in non-UNIX client workspaces appear as small text files containing a relative path to the linked file. Editing these files on a non-UNIX client should be done with caution, because submitting them to the depot might result in a symbolic link pointing to a nonexistent file on the UNIX workspace.

- Changing a file’s type does not affect earlier revisions stored in the depot.

  For instance, changing a file’s type by adding the `+S`n`` (temporary object) modifier tells Perforce to store only the most recent `n` revisions of the file in the depot. If you change an existing file into a temporary object, subsequent revisions (after the `n`th) will purge the revisions stored after the old head revision, but revisions to the file stored in the depot before the `+S`n`` modifier was used will remain unaffected. (Syncing to a non-head revision submitted after the `+S`n`` modifier was used will delete the file from your workspace. Such revisions are displayed as `purge` operations in the output of `p4 filelog`.)

- Running `p4 integrate` on temporary object files (`+S` and `+S`n``) does not produce a lazy copy. The integrated `tempobj` file consumes additional disk space on the shared versioning service.

- The modtime (`+m`) modifier is a special case: It is intended for use by developers who need to preserve a file’s original timestamp.

  If a client workspace uses the `modtime` option, the file date is not guaranteed to advance for each revision. For example, if a file is copy integrated ("accept theirs"), its timestamp will reflect that of the source file. If a user checks in a file with an old date, the client workspace file will reflect that same, old date. Normally, Perforce updates the timestamp when a file is synced. The modtime option enables a user to ensure that the timestamp of a file in a client workspace after a `p4 sync` will be the original timestamp existing on the file at the time of submission (that is, not the time at the Perforce versioning service at time of submission, and not the time on the user’s workstation at the time of sync).

  The most common case where this is useful is development involving the third-party DLLs often encountered in Windows environments. Because the timestamps on such files are often used as proxies for versioning information (both within the development environment and also by the operating system), it is sometimes necessary to preserve the files' original timestamps regardless of a Perforce user’s client settings.

  If the `+m` modifier on a file is set, when syncing the file Perforce restores the file’s original timestamp at the time of submit. This means that Perforce ignores:

  - the `modtime` ("file’s timestamp at time of submission")
  - the `nomodtime` ("date and time on the client at time of sync") option setting of the client workspace

- Versions of Perforce prior to the year 2000 used a set of keywords to specify file types. The following table lists the older keywords and their current base file types and modifiers:

  Old Keyword | Description | Base Filetype | Modifiers
  --- | --- | --- | ---
  `text` | Text file | `text` | none
  `xtext` | Executable text file | `text` | `+x`
  `ktext` | Text file with RCS keyword expansion | `text` | `+k`
  `kxtext` | Executable text file with RCS keyword expansion | `text` | `+kx`
  `binary` | Non-text file | `binary` | none
  `xbinary` | Executable binary file | `binary` | `+x`
  `ctext` | Compressed text file | `text` | `+C`
  `cxtext` | Compressed executable text file | `text` | `+Cx`
  `symlink` | Symbolic link | `symlink` | none
  `ltext` | Long text file | `text` | `+F`
  `xltext` | Executable long text file | `text` | `+Fx`
  `ubinary` | Uncompressed binary file | `binary` | `+F`
  `uxbinary` | Uncompressed executable binary file | `binary` | `+Fx`
  `tempobj` | Temporary object | `binary` | `+FSw`
  `ctempobj` | Temporary object (compressed) | `binary` | `+Sw`
  `xtempobj` | Temporary executable object | `binary` | `+FSwx`
  `xunicode` | Executable unicode | `unicode` | `+x`
  `xutf16` | Executable UTF-16 | `utf16` | `+x`

Your search for returned results