Talk:MAC times
Latest comment: 9 years ago by Techie007 in topic False statements and incorrect conflation of change time and creation time
![]() | This article has not yet been rated on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | ||||||||||
|
I'll chime in to explain the bias I see. A "de facto" standard is entirely subjective. In this case one may view it from amount of file systems or the adoption rate of the standard. This correlates to the Unix and Windows de facto standards with Windows holding the higher adoption rate and Unix having more file systems. Neither is better. 173.123.68.222 (talk) 05:14, 13 August 2009 (UTC)
- That's a ridiculous definition of standards, and a misunderstanding of what "unix" is. A de facto standard emerges if several different independent implementations all agree to the same conventions for the purpose of interoperability. There are many independent unix-like systems (most of which largely conform to the formal POSIX standard), and even more unix-compatible file systems, and they've all agreed to manage MAC times using the same semantics. Microsoft has alone decided to do something different, and nobody else has chosen to follow their lead in the name of interoperability, thus what they are doing is not a standard in any sense. Just because a market leader does something doesn't mean it's a standard. Rvcx (talk) 11:02, 13 August 2009 (UTC)
False statements and incorrect conflation of change time and creation time
edit- Unix and Windows file systems interpret 'ctime' differently:
- Unix systems maintain the historical interpretation of ctime as being the time when certain file metadata, not its contents, were last changed, such as the file's permissions or owner (e.g. 'This files metadata was changed on 05/05/02 12:15pm').
- Windows systems use ctime to mean 'creation time' (also called 'birth time') (e.g. 'This file was created on 05/05/02 12:15pm').
- Remove: incorrect. Windows systems do track a real ctime (in the Unix fashon) internally, and if you use the Cygwin tools, you will see it. There are 4 times tracked on Windows.12.198.223.226 (talk) 18:32, 4 June 2012 (UTC)
- It's actually somewhat more complex than that, 12.198.223.226, given that "Windows" is not solely Windows NT. But the core of your complaint is spot on. This article is just outright wrong about Windows, Win32, Cygwin, SMB, and other stuff in several places. Jonathan de Boyne Pollard (talk) 15:39, 19 January 2014 (UTC)
- User 12.198.223.226 (talk) is correct in that Windows does store a traditional ctime. Internally, Windows has four file times: Modified, Accessed, Created, and Changed. That last one is not seen anywhere in the Windows UI, nor is it accessable through the traditional GetFileTime API, but it is stored in the MFT. That said, I support the article saying that "ctime" is file creation time in Windows, since that's what the UI and APIs expose. Techie007 (talk) 01:50, 14 March 2015 (UTC)