Jump to content


When does p4 client 'Access' time get updated?


  • Please log in to reply
13 replies to this topic

#1 carljohnson

carljohnson

    Newbie

  • Members
  • Pip
  • 1 posts

Posted 13 September 2019 - 04:29 PM

This is described as "The date this client was last used in any way"

Running the command:
`p4 flush file.txt@some_client`

Doesn't seem to update the 'Access' time on 'some_client'

Our use case is as follows:
We scale up cloud instances based on an original image which had perforce synced, then these new instances flush their own client workspace to match the original instances client.

Our cleanup script which deletes workspaces older than X can accidentally delete this original workspace, since it is impossible to tell that it is actually in use.

Should this access time actually be getting updated in this case?

Assume I am using latest p4 binaries for client and server

#2 Matt Janulewicz

Matt Janulewicz

    Advanced Member

  • Members
  • PipPipPip
  • 187 posts
  • LocationSan Francisco, CA

Posted 01 October 2019 - 10:22 PM

It would be interesting to know, from a p4d developer, if this is intended, because I would agree that intuitively it feels like it should be updated. I don't have much else to add.

This feels similar to the fact that if you use 'p4 client -t' to create or update a client view, the access date doesn't change, either.
-Matt Janulewicz
Staff SCM Engineer, Perforce Administrator
Dolby Laboratories, Inc.
1275 Market St.
San Francisco, CA 94103, USA
majanu@dolby.com

#3 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 947 posts

Posted 02 October 2019 - 06:12 AM

IIRC the "Access" is updated when the client is part of the context of a command execution (i.e. the P4CLIENT), not when it's the target of some other command's query (which would include not just @client rev syntax but also potentially "opened -a" or "p4 clients" etc).  There might also be some constraints around the type of operation, but I'm not positive about that.  Updates to the Access timestamps are only made with a granularity of about five minutes, so it's a little difficult to verify experimentally.

For the specific use case you describe, a label might be a better option than a client...

#4 Matt Janulewicz

Matt Janulewicz

    Advanced Member

  • Members
  • PipPipPip
  • 187 posts
  • LocationSan Francisco, CA

Posted 03 October 2019 - 07:19 PM

I wanted to mention a pet peeve about this subject that I haven't griped about in 10 years or so. :)

Regarding 'p4 client -t', it would be nice if the Access was updated in that case since there's really no designation on what client can be used as a template. When an admin wants to do some housecleaning and maybe prune some of the 100's of thousands of client specs lying around, an intuitive place to start is Access. Which inevitably results in one wiping out a lot of client specs that are used as templates.

It might not hold up in the court of law, but one could probably make a compelling argument that using a client spec as a template does "access" it since it has to open it to get the View, etc. out of it.

Just sayin'. :P
-Matt Janulewicz
Staff SCM Engineer, Perforce Administrator
Dolby Laboratories, Inc.
1275 Market St.
San Francisco, CA 94103, USA
majanu@dolby.com

#5 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 947 posts

Posted 03 October 2019 - 08:59 PM

Not a problem if you use streams.  B)

#6 Miles O'Neal

Miles O'Neal

    Advanced Member

  • Members
  • PipPipPip
  • 144 posts

Posted 04 October 2019 - 02:52 PM

Matt, my feeling exactly. Access time should mean last time accessed, across the board. If you want something else, add a something-else-time field with a more descriptive name.
Cleanup is where I feel the pain most on this, too.

#7 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 947 posts

Posted 04 October 2019 - 09:22 PM

By a strict "across the board" metric it's safe to assume that every client is being accessed more or less continuously, by virtue of the fact that anyone who has P4V open to the clients tab is running "p4 clients" and listing all clients every N minutes.

#8 Miles O'Neal

Miles O'Neal

    Advanced Member

  • Members
  • PipPipPip
  • 144 posts

Posted 04 October 2019 - 09:39 PM

But does listing the available clients actually access each client? Or just its metadata? I wouldn't think it accessed the client.
It still may be too generous, because I wasn't thinking about, say, "p4 client -o". But I think that has to count as an access as well, however innocuous.

#9 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 947 posts

Posted 05 October 2019 - 03:18 PM

View PostMiles O, on 04 October 2019 - 09:39 PM, said:

But does listing the available clients actually access each client? Or just its metadata? I wouldn't think it accessed the client.

A "client" consists of the actual files on disk and the metadata; all of the commands we've been talking about ("p4 client -t CLIENT", "p4 client -o CLIENT", "p4 clients", "p4 flush @CLIENT", "p4 opened -a") operate solely on metadata, and they're all read-only operations.  "p4 clients" is reductio ad absurdum, but I use it to make the point that there needs to be some sort of (somewhat arbitrary) restrictive judgement call about what counts as "access" in order for the "Access" field to have any meaning at all.

I'm pretty sure that anything that writes to the client metadata (anything where you're operating on files in your workspace will meet that bar, I think) will bump the "Access" field, and anything that writes to the stuff you can see in the client spec (so the domain and view record, but not the have/working lists) will additionally bump the "Update" field.  I could be wrong about that though, I feel like I've hit cases where a timestamp got (or didn't get) updated that didn't seem to follow any sort of obvious logic.  The five minute granularity issue adds an extra layer of confusion when trying to experiment with these things since sometimes the non-obvious reason the timestamp didn't get bumped is that it already had been bumped recently enough to not be deemed worth the hit of a db write.

Ideally there'd be a queryable audit log that you could filter for specific operations so that a single timestamp wouldn't need to be all things for all use cases.  Probably possible to do that with structured logging...?

#10 Matt Janulewicz

Matt Janulewicz

    Advanced Member

  • Members
  • PipPipPip
  • 187 posts
  • LocationSan Francisco, CA

Posted 07 October 2019 - 11:56 PM

Do "p4 client -t" and "p4 client -o" really only operate on metadata? That doesn't seem right, as those use/display the actual spec, which would insinuate accessing the library file for the spec.

My gut feeling is that if something accesses the content of the library file, that should be an access. But metadata-only (p4 clients) are not an access.
-Matt Janulewicz
Staff SCM Engineer, Perforce Administrator
Dolby Laboratories, Inc.
1275 Market St.
San Francisco, CA 94103, USA
majanu@dolby.com

#11 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 947 posts

Posted 08 October 2019 - 03:13 AM

View PostMatt Janulewicz, on 07 October 2019 - 11:56 PM, said:

Do "p4 client -t" and "p4 client -o" really only operate on metadata? That doesn't seem right, as those use/display the actual spec, which would insinuate accessing the library file for the spec.

The spec is generated from the metadata, specifically the db.domain and db.view tables.  One db.view entry per View or ChangeView line, and everything else is packed into one db.domain entry.  

There is no "library file" for a spec unless you have a spec depot, and if you do have a spec depot the "source of truth" is still the database (the spec depot is solely used as a backup during write operations).

#12 Miles O'Neal

Miles O'Neal

    Advanced Member

  • Members
  • PipPipPip
  • 144 posts

Posted 09 October 2019 - 04:30 PM

I think what would really be helpful would be something like the following. I have wanted each of these at some point.
Client spec updated
Depot data updated *
On-disk data updated *
Client spec accessed
Depot data accessed *
On-disk data accessed *

* Through this client

#13 Matt Janulewicz

Matt Janulewicz

    Advanced Member

  • Members
  • PipPipPip
  • 187 posts
  • LocationSan Francisco, CA

Posted 10 October 2019 - 12:43 AM

View PostSambwise, on 08 October 2019 - 03:13 AM, said:

The spec is generated from the metadata, specifically the db.domain and db.view tables.  One db.view entry per View or ChangeView line, and everything else is packed into one db.domain entry.  

There is no "library file" for a spec unless you have a spec depot, and if you do have a spec depot the "source of truth" is still the database (the spec depot is solely used as a backup during write operations).

Oh yeah, derp. It's been so long that I forget that //spec/ isn't a default thing. :)

Anyway, in my mind, from a conceptual standpoint, if a function has to 'open' the spec and look at the contents, that feels like an access.

In my selfish, narrow view, I want to avoid removing 'old' specs that are actually still 'in use'.
-Matt Janulewicz
Staff SCM Engineer, Perforce Administrator
Dolby Laboratories, Inc.
1275 Market St.
San Francisco, CA 94103, USA
majanu@dolby.com

#14 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 947 posts

Posted 10 October 2019 - 01:38 AM

When I implemented similar cleanup logic for the Public Depot many years ago, I ended up basing it on the user (with "registered" users being automatically exempted from cleanup operations and everyone else getting something like a 1-year grace period), and I just deleted the clients along with the user that owned them, leaving it up to active users to manage their own clients.  Precisely because figuring out how/if someone's "using" a client is so fuzzy, and improperly deleting a client is fairly destructive.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users