Skip to content

ctime: I don't think that word means what you think it means. #49970

Closed
#102149
Closed
ctime: I don't think that word means what you think it means.#49970
#102149
Labels
stdlibStandard Library Python modules in the Lib/ directory

Description

@zooko
zooko
mannequin
opened on Apr 7, 2009
BPO 5720
Nosy @pitrou, @benjaminp, @ezio-melotti

Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2009-04-07.21:57:48.223>
labels = ['library']
title = "ctime: I don't think that word means what you think it means."
updated_at = <Date 2013-08-23.23:55:49.251>
user = 'https://bugs.python.org/zooko'

bugs.python.org fields:

activity = <Date 2013-08-23.23:55:49.251>
actor = "Zooko.Wilcox-O'Hearn"
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2009-04-07.21:57:48.223>
creator = 'zooko'
dependencies = []
files = []
hgrepos = []
issue_num = 5720
keywords = []
message_count = 11.0
messages = ['85750', '85987', '89336', '195477', '196050', '196052', '196056', '196058', '196059', '196060', '196061']
nosy_count = 5.0
nosy_names = ['zooko', 'pitrou', 'benjamin.peterson', 'ezio.melotti', "Zooko.Wilcox-O'Hearn"]
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = None
url = 'https://bugs.python.org/issue5720'
versions = ['Python 3.4']

Activity

  1. zooko commented on Apr 7, 2009

    @zooko
    zookomannequin
    on Apr 7, 2009
    MannequinAuthor

    The stat module currently uses the "st_ctime" slot to hold two kinds
    values which are semantically different but which are frequently
    confused with one another. It chooses which kind of value to put in
    there based on platform -- Windows gets the file creation time and all
    other platforms get the "ctime". The only sane way to use this API is
    then to switch on platform:

    if platform.system() == "Windows":
    metadata["creation time"] = s.st_ctime
else:
    metadata["unix ctime"] = s.st_ctime

    (That is an actual code snippet from the Allmydata-Tahoe project.)

    Many or even most programmers incorrectly think that unix ctime is file
    creation time, so instead of using the sane idiom above, they write the
    following:

    metadata["ctime"] = s.st_ctime

    thus passing on the confusion to the users of their metadata, who may
    not know on which platform this metadata was created. This is the
    situation we have found ourselves in for the Allmydata-Tahoe project --
    we now have a bunch of "ctime" values stored in our filesystem and no
    way to tell which kind they were.

    More and more filesystems such as ZFS and Macintosh apparently offer
    creation time nowadays.

    I propose the following changes:

    1. Add a "st_crtime" field which gets populated on filesystems
      (Windows, ZFS, Mac) which can do so.

    That is hopefully not too controversial and we could proceed to do so
    even if the next proposal gets bogged down:

    1. Add a "st_unixctime" field which gets populated *only* by the unix
      ctime and never by any other value (even on Windows, where the unix
      ctime *is* available even though nobody cares about it), and deprecate
      the hopelessly ambiguous "st_ctime" field.

    You may be interested in http://allmydata.org/trac/tahoe/ticket/628
    ("mtime" and "ctime": I don't think that word means what you think it
    means.) where the Allmydata-Tahoe project is carefully unpicking the
    mess we made for ourselves by confusing ctime with file-creation time.

  2. zooko
    added
    stdlibStandard Library Python modules in the Lib/ directory
    on Apr 7, 2009

  3. pitrou commented on Apr 15, 2009

    @pitrou
    pitrou
    on Apr 15, 2009
    Member

    Sounds like a good idea, perhaps you could launch a discussion on
    python-dev?

  4. zooko commented on Jun 13, 2009

    @zooko
    zookomannequin
    on Jun 13, 2009
    MannequinAuthor

    Okay, I posted to python-dev:

    http://mail.python.org/pipermail/python-dev/2009-June/090021.html

  5. ezio-melotti commented on Aug 17, 2013

    @ezio-melotti
    ezio-melotti
    on Aug 17, 2013
    Member

    What was the outcome?

  6. ZookoWilcox-OHearn commented on Aug 23, 2013

    @ZookoWilcox-OHearn
    ZookoWilcox-OHearnmannequin
    on Aug 23, 2013
    Mannequin

    Well, read the thread! http://mail.python.org/pipermail/python-dev/2009-June/090021.html

    Basically just a couple of +1's, and a good suggestion to name it something clearer than "crtime".

    Please fix it!

  7. benjaminp commented on Aug 23, 2013

    @benjaminp
    benjaminp
    on Aug 23, 2013
    Contributor

    I don't think we should hijack st_ctime. All the other members of the stat object correspond exactly to what you get back from the Unix stat() call. Let's not break that. How about just leaving st_ctime as it is and adding st_creationtime, which will have the nicer semantics?

  8. ZookoWilcox-OHearn commented on Aug 23, 2013

    @ZookoWilcox-OHearn
    ZookoWilcox-OHearnmannequin
    on Aug 23, 2013
    Mannequin

    Benjamin Peterson: what do you mean "hijack ctime"? I don't think I — or anyone — has proposed anything that fits that description. Please be more specific. My proposal in http://bugs.python.org/issue5720#msg85750 does not break anything.

  9. benjaminp commented on Aug 23, 2013

    @benjaminp
    benjaminp
    on Aug 23, 2013
    Contributor

    Indeed, "hijacking" is a bit strong. I mean filling it with a value that is not in the underlying st_ctime field from stat() call.

  10. ZookoWilcox-OHearn commented on Aug 23, 2013

    @ZookoWilcox-OHearn
    ZookoWilcox-OHearnmannequin
    on Aug 23, 2013
    Mannequin

    Benjamin: I'm sorry, I still don't understand. Do you think my proposal would involve setting something named "ctime" to contain a value that didn't come from the underlying stat "ctime"?

  11. benjaminp commented on Aug 23, 2013

    @benjaminp
    benjaminp
    on Aug 23, 2013
    Contributor

    You're quite right. I stupidly misread "crtime" as "ctime".

  12. ZookoWilcox-OHearn commented on Aug 23, 2013

    @ZookoWilcox-OHearn
    ZookoWilcox-OHearnmannequin
    on Aug 23, 2013
    Mannequin

    Aha! Mystery solved. I wouldn't say that you were stupid — I would say that "crtime" is way too close to "ctime", and I strongly agree with the suggestion (http://mail.python.org/pipermail/python-dev/2009-June/090026.html) on the mailing list by Greg Ewing that we name the new thing something more obvious.

  13. ezio-melotti
    transferred this issue fromon Apr 10, 2022
  14. zooba
    closed this as completedin #102149on Mar 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    stdlibStandard Library Python modules in the Lib/ directory

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions