Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
zooko mannequin opened this issue Apr 7, 2009 · 11 comments · Fixed by #102149
Closed

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

zooko mannequin opened this issue Apr 7, 2009 · 11 comments · Fixed by #102149
Labels
stdlib Python modules in the Lib dir

Comments

@zooko
Copy link
Mannequin

zooko mannequin commented 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']

@zooko
Copy link
Mannequin Author

zooko mannequin commented Apr 7, 2009

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.

@zooko zooko mannequin added the stdlib Python modules in the Lib dir label Apr 7, 2009
@pitrou
Copy link
Member

pitrou commented Apr 15, 2009

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

@zooko
Copy link
Mannequin Author

zooko mannequin commented Jun 13, 2009

Okay, I posted to python-dev:

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

@ezio-melotti
Copy link
Member

What was the outcome?

@ZookoWilcox-OHearn
Copy link
Mannequin

ZookoWilcox-OHearn mannequin commented Aug 23, 2013

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!

@benjaminp
Copy link
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?

@ZookoWilcox-OHearn
Copy link
Mannequin

ZookoWilcox-OHearn mannequin commented Aug 23, 2013

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.

@benjaminp
Copy link
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.

@ZookoWilcox-OHearn
Copy link
Mannequin

ZookoWilcox-OHearn mannequin commented Aug 23, 2013

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"?

@benjaminp
Copy link
Contributor

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

@ZookoWilcox-OHearn
Copy link
Mannequin

ZookoWilcox-OHearn mannequin commented Aug 23, 2013

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stdlib Python modules in the Lib dir
Projects
None yet
3 participants