-
-
Notifications
You must be signed in to change notification settings - Fork 31.7k
ctime: I don't think that word means what you think it means. #49970
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
Comments
The stat module currently uses the "st_ctime" slot to hold two kinds 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 metadata["ctime"] = s.st_ctime thus passing on the confusion to the users of their metadata, who may More and more filesystems such as ZFS and Macintosh apparently offer I propose the following changes:
That is hopefully not too controversial and we could proceed to do so
You may be interested in http://allmydata.org/trac/tahoe/ticket/628 |
Sounds like a good idea, perhaps you could launch a discussion on |
Okay, I posted to python-dev: http://mail.python.org/pipermail/python-dev/2009-June/090021.html |
What was the outcome? |
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! |
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? |
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. |
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. |
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"? |
You're quite right. I stupidly misread "crtime" as "ctime". |
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. |
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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: