[issue5720] ctime: I don't think that word means what you think it means.
Zooko Wilcox-O'Hearn added the comment: 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! -- nosy: +Zooko.Wilcox-O'Hearn ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5720 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5720] ctime: I don't think that word means what you think it means.
Benjamin Peterson added the comment: 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? -- nosy: +benjamin.peterson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5720 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5720] ctime: I don't think that word means what you think it means.
Zooko Wilcox-O'Hearn added the comment: 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. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5720 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5720] ctime: I don't think that word means what you think it means.
Benjamin Peterson added the comment: 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. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5720 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5720] ctime: I don't think that word means what you think it means.
Zooko Wilcox-O'Hearn added the comment: 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? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5720 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5720] ctime: I don't think that word means what you think it means.
Benjamin Peterson added the comment: You're quite right. I stupidly misread crtime as ctime. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5720 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5720] ctime: I don't think that word means what you think it means.
Zooko Wilcox-O'Hearn added the comment: 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. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5720 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5720] ctime: I don't think that word means what you think it means.
Ezio Melotti added the comment: What was the outcome? -- nosy: +ezio.melotti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5720 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5720] ctime: I don't think that word means what you think it means.
Changes by Ramchandra Apte maniandra...@gmail.com: -- versions: +Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5720 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5720] ctime: I don't think that word means what you think it means.
Zooko O'Whielacronx zo...@zooko.com added the comment: Okay, I posted to python-dev: http://mail.python.org/pipermail/python-dev/2009-June/090021.html -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5720 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5720] ctime: I don't think that word means what you think it means.
Antoine Pitrou pit...@free.fr added the comment: Sounds like a good idea, perhaps you could launch a discussion on python-dev? -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5720 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5720] ctime: I don't think that word means what you think it means.
New submission from Zooko O'Whielacronx zo...@zooko.com: 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: 2. 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. -- components: Library (Lib) messages: 85750 nosy: zooko severity: normal status: open title: ctime: I don't think that word means what you think it means. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5720 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
