Perforce Public Knowledge Base - File Modification Times
Perforce Software logo
Reset Search
 

 

Article

File Modification Times

« Go Back

Information

 
Problem
This article discusses how Perforce handles file modification timestamps and the settings that affect the timestamp Perforce puts on files synced to a client workspace.

 

Solution

Summary

This article discusses how Perforce handles file modification timestamps and the settings that affect the timestamp Perforce puts on files synced to a client workspace.

What Timestamps are placed on Files Synced to a Client Workspace?

The post-sync timestamp can be one of only two values, the pre-submit timestamp or the sync time. By default Perforce sets the post-sync timestamp to be the sync time. The submit time, also called the changelist time, is never used with files synced to a client workspace.

Which Settings Determine the Timestamp Perforce places on a File During a Sync?

Two parameters affect which timestamp is used for the post-sync timestamp, the +m filetype modifier and the [no]modtime option in the client specification used to perform the sync operation.

The +m FileType Modifier

The filetype of a file revision is set when the revision is checked into the depot and can not be changed for an existing file revision. Therefore, the filetype of a file revision, including any +m filetype modifier, is always the same during a sync operation as is was at submit time for that file revision. Different revisions of the same file can have different filetypes and different +m filetype modifier settings. When syncing a file, Perforce considers only the +m filetype setting for the particular revision being synced and ignores the setting on other revisions.

+m filetype modifier set

Having the +m filetype modifier set on a file revision at submit time will always cause the post-sync timestamp to be set to the same value as the pre-submit timestamp for that file revision during a sync operation. Or, put another way, having the +m filetype modifier set on a file when it is submitted to the depot will preserve the modification time of that version of the file through the process of checkin and checkout.

+m filetype modifier unset

Having the +m filetype modifier not set on a file revision at submit time, the default, will permit sync time parameters to affect which post-sync timestamp will be places on that version of the file during a sync operation. Or put another way, having the +m filetype modifier unset on a file when it is submitted to the depot will allow sync time parameters to determine which modification timestamp will be place on that version of the file during a sync operation.
The +m file modifier can be set by using the "-t" flag of the p4 add, p4 edit and p4 reopen commands. See file types for more details.

The value of the +m filetype modifier can be viewed in the output of the p4 filelog command and in the headType field in the output of the p4 fstat command.

The [no]modtime Client Specification Option

The [no]modtime client specification option is a parameter that can only have an effect at sync time and then only if the file revision being synced has the +m filetype modifier unset.

[no]modtime = modtime

The post-sync timestamp will be set to the pre-submit timestamp.

 

[no]modtime = nomodtime

The post-sync timestamp will be set to the sync time.

Note: The value of the [no]modtime option has no effect whatsoever at submit time.
 

Summary of Parameters Affecting Timestamps

Parameter
+m Filetype Modifier
Parameter
[no]modtime Client Spec Option
Timestamp Put on Workspace File During Sync
filetype
nomodtime
filetype
modtime
filetype+m
nomodtime
filetype+m
modtime
 

Viewing the File Modification Time for a File Revision

When a file revision is submitted, Perforce records the pre-submit timestamp. This time can be seen in the "headModTime" field in the output of the p4 fstat command:
p4 fstat //depot/path/to/a/file#revNum
...
headModTime 1315802161
...
This time is not easily human readable.  It is shown as the number of seconds since the UNIX epoch, 00:00:00 UTC, January 1, 1970. Converting from UNIX time format to a more human readable local time format varies between operating systems and programming languages.  When converting, make sure the converter uses a timezone appropriate for the client location or the convertor incorrect results.  An online epoch coverter is available from here.

When comparing modtimes to filesystem timestamps it may be easier to convert the modtime on a file to seconds since the epoch. An example of doing this under UNIX is as follows:
# Display a file modtime in UNIX time
$ stat -f "%m" -t "%s" aFile
1315783528

Example of Using Modtimes

Natasha is working in Sydney Australia where her local time is UTC+10. Natasha modified a file in her workspace a few days ago and is now adding it to the depot for the first time:
$ ls -lT depot/aFile
-rw-r--r--  1 natasha  devels  806 12 Sep 09:25:28 2011 aFile

# Display the modtime in UNIX time
$ stat -f "%m" -t "%s" depot/aFile

1315783528

$ p4 add depot/aFile
...
$ p4 submit -d "Added aFile of type text"
...
$ date
Fri 16 Sep 2011 15:29:40 EST
From the above Natasha can see that:
pre-submit timestamp  = 12 Sep 09:25:28 2011 (1315783528)
submit time           = 16 Sep 15:29:40 2011 (approximately)
By examining the output of the p4 fstat command Natasha can confirm that Perforce has recorded these times, as well as the filetype, for this initial revision:
$ p4 fstat depot/aFile
...
... headType text
... headTime 1316150979
... headModTime 1315783528
...

$ # Converting to local time with the date -r command on her Mac
$ date -r 1316150979
Fri 16 Sep 2011 15:29:39 EST
Which gives:
headType text          - filetype is text and +m modifier is NOT set
headTime 1316150979    - #sync time of Fri 16 Sep 2011 15:29:39 EST
headModTime 1315783528 - #pre-submit of Mon 12 Sep 2011 09:25:28 EST
Some days after submitting the file Natasha forces a sync of the file revision to her workspace and finds that the post-sync timestamp is the same as the "sync time".
$ p4 sync -f depot/aFile
...
$ ls -lT depot/aFile
-r--r--r--  1 natasha  devels  806 20 Sep 11:00:56 2011 depot/aFile
$ date
Tue 20 Sep 2011 11:00:58 EST
Natasha needs Perforce to preserve the pre-submit timestamp through checkin and checkout as the build script will trigger a time consuming rebuild of modules dependent upon "depot/aFile" if the files timestamp changes. Checking her workspace options:
$ p4 client -o | grep ^Options:
Options: noallwrite noclobber nocompress unlocked nomodtime normdir
Natasha sees that the default option of "nomodtime" is in effect so she edits her client specification to change this to "modtime" so the post-sync timestamp and the pre-submit timestamp will be the same. Then Natasha resyncs the file:
$ p4 client -o | sed -e "s/ nomodtime / modtime /" | p4 client -i
$ p4 client -o | grep ^Options:
Options:        noallwrite noclobber nocompress unlocked modtime normdir

$ p4 sync -f depot/aFile
...

$ ls -lT depot/aFile
-r--r--r--  1 natasha  devels  806 12 Sep 09:25:28 2011 depot/aFile
The modtime option in her client specification has preserved the pre-submit timestamp. However, Natasha wants the default "nomodtime" behavior for other files she is syncing and does not want all her colleagues to have to remember to adjust their client specifications each time they want to sync this particular file to do a build.

Natasha instructs Perforce to maintain the pre-submit timestamp for future revisions of "depot/aFile" for all users no matter what their [no]modtime client workspace option is set to. She does this by setting set the +m filetype modifier for the file. As a filetype can not be changed for a particular revision Natasha needs to submit a new revision in order to do this.

Natasha adds the +m filetype modifier to the existing filetype while checking out the file. She then resubmits the file and compares the headType and headModTime for both file revisions to confirm that the headModTime is the same and the +m fileType modifier has been added to the second revision.
$ p4 edit -t +m  depot/aFile
$ p4 submit -d "+m filetype modifier preserves pre-submit timestamp"

$ p4 fstat depot/aFile#1
...
... headType text
... headTime 1316150979
... headModTime 1315783528
...

$ p4 fstat depot/aFile
...
... headType text+m
... headTime 1316575174
... headModTime 1315783528
...
As a final check Natasha confirms that the post-sync timestamp is "12 Sep 09:25:28 2011" no matter the value of her [no]modtime client specification settings:
$ p4 client -o | grep ^Options:
Options: noallwrite noclobber nocompress unlocked nomodtime normdir
$
$ rm -f depot/file
$ p4 sync -f depot/aFile
...

$ ls -lT depot/aFile
$-r--r--r--  1 natasha  devels  806 12 Sep 09:25:28 2011 depot/aFile

$ p4 client -o | sed -e "s/ nomodtime / modtime /" | p4 client -i
$ p4 client -o | grep ^Options:
Options:    noallwrite noclobber nocompress unlocked modtime normdir

$ rm -f depot/aFile
$ p4 sync -f depot/aFile
...
$ ls -lT depot/aFile
-r--r--r--  1 natasha  devels  806 12 Sep 09:25:28 2011 depot/aFile
This is exactly what Natasha wanted. The pre-submit timestamp has been preserved for all users no matter the value of [no]modtime in their client specification settings.

Glossary

pre-submit timestamp

The modification time, or modtime of the file as it resides in the client workspace when the file is submitted to the depot. This is a timestamp marking the last time the file revision was modified prior to submission to the depot.

post-sync timestamp

The modification time, or modtime, of a file copied by Perforce to a client workspace during a sync operation.

sync time

The time at which a file revision is synced from the depot to the client workspace.

submit time

The time a revision is submitted to the depot. This time is also called the "changelist time" as this is the time the changelist containing the revision was submitted. This is the time displayed by the p4 filelog and p4 describe commands. (the p4 filelog command will display the "time" portion as well as the "date" by specifying the -t flag.)
 
Related Links

Feedback

 

Was this article helpful?


   

Feedback

Please tell us how we can make this article more useful.

Characters Remaining: 255