I don't get it. Isn't the oldest file is limited by the purchase date of my computer?
Isn't the question equivalent to "Ask HN: who has the oldest running computer?"
For the young'uns, "Shirley" is a reference to a cultural phenomenon in the early 80's through early 90's around a line that would go something like this: "Surely it's an operating system file. Yes of course, but don't call me Shirley!" It was started by a popular movie, but became widespread throughout the culture.
Alternatively, it could have been a speech to text accident and I'm reading way too much into it. I choose to disregard that possibility. Shirley you understand.
I guess the only sane way to measure this is the age of the file content, not timestamp. In that case anyone with any non-trivial sequence of sequenced genomic data wins hands down (millions to billions of years).
The puzzle is to figure out which parts are billions of years old, and which parts are 10 years old, and which parts are false reads.
In any case, astronomy has that beat hands down, as with https://en.wikipedia.org/wiki/Maisie's_Galaxy ("Maisie's Galaxy (also known as CEERS J141946.36+525632.8) is a distant galaxy located at z=11.4 that existed 390 million years after the beginning of the universe.")
Mac users using iCloud, be careful about attempting to "stat" the entire filesystem, this will cause iCloud Drive to download its entire contents onto your local disk.
“I suspect these new evicted files take advantage of a trick in APFS: as far as I can tell, they consist of the file with its attributes and extended attributes intact and stored locally, but no extents for its data. Thus, when you ask for the file size, it returns the size it would be when downloaded, although the file only takes the space required for its attributes and extended attributes, until it has been downloaded.”
“Check if a file is dataless and then only access it in a safe context. To do the check, call stat or getattrlist and examine if SF_DATALESS is present in stat.st_flags. Be aware that stat and getattrlist both trigger the materialization of any intermediate folders in the file’s path, if they themselves are dataless.”
⇒ doing stat on an entire filesystem will materialize all directories, but not its files.
This brings up a related point that for the longest time (to my knowledge) Linux filesystems lacked creation timestamps, so only the last modified was preserved.
While even now with the filesystems that support them they're tied to that instance of the filesystem (ie: non-modifiable, unlike Windows), which has always puzzled me given the need to variously restore from backups (or just have an identical copy in a destination) where one would desire such info*.
* When I last looked into this I saw some quite creative workarounds, such as a script loop where for each file to be copied it changed the system clock to the date of the timestamp, so it was recreated in the destination.
Can save & restore both btime & ctime via "underhanded" filesystem debugging utility scripting. (It is in Nim which might be an obstacle for some, but honestly it is a very simple program to port to whatever.)
creation time is a nontrivial problem. when i copy a file to a new location (or unpack it from an archive, download it, etc...) is the creation time the time the file is saved or the time it was historically created. and if it is the first, and then you modify the file by making a copy of it and deleting the original (so the inode changes), does the creation time change, or should it be copied from the old version?
so there are 4 different values:
the original time when a file was originally created.
the time when it was first created on this device.
the time when a particular inode was created.
the time when the content of the file was modified.
and you could add more: if the file contains a story, how about the time the original story was written?
or the time the content (and not the metadata, like the exif data of an image) was modified?
there are use cases for each. but of all of them the last modified time is the easiest to reason about.
On NTFS (under Windows) it's handled rather straightforwardly. When a file is originally created it's given a date created timestamp. If the file is copied naively the date created timestamp changes to that of the copy time, while the date modified remains intact.
However it's easy to preserve the date created timestamp during a copy using the native Robocopy utility, among many other methods. It's simply treated as date modified is: modifiable and arbitrary.
This makes restoring from backups sensible. Have a drive that has died? Can do a file-based restore without the need for images and preserve such metadata. Individual file unexpectedly deleted? Restore it and regain the timestamps. The benefit is one has a transferable reference for when files were originally made, even if they lack internal metadata that stores this (such as eg: EXIF for images).
Under Linux, even with its now kernel-based NTFS support, it just adds NTFS-specific data like date creation timestamps as peripheral extended attributes, which Linux file managers broadly don't expose or handle well. While native filesystems like EXT4 which support creation time are impractically limited to unmodifiable date creation timestamps based on their first creation on that particular instance of the filesystem, without hacky and fragile workarounds.
That is despite `touch` being ubiquitous on Linux for modifying date modified timestamps (showing that in practical terms, it's considered similarly arbitrary metadata) which from what I've seen Linux users appear to have no disagreements with about its utility.
As a Windows user who would like to migrate to Linux this aspect makes it frustratingly a non-starter, as even if one uses SMB to access the files (adding its own layer for such compatible metadata, regardless of the underlying filesystem) Linux file managers still don't handle well extended attributes so management for such files under Linux isn't at parity.
Not quite what you’re asking, but I’ve got animations I made in Deluxe Paint III on the Amiga still kicking around, 33 years later, and some Dark Forces wads from nearly 30 years ago. So much more has been lost over the years from media rot, but a few bits (bytes?) I’ve managed to hang on to.
I have some papers from the late 90s. I purposefully saved them in rtf to make them more portable, but they are mangled now. Not sure if the standard changed or the files are corrupt. I suppose I should have wrote everything in plain text, but who has that kind of forethought in high school…
A text file of a list of people from December 12, 1981. Originally had it on a floppy for the IBM PC 5150 and it's made the leap somehow to every new system for over 40 years.
I am convinced (convinced) that in a distant future the answer to some then-unsurmountable technology problem will be found in the depths of some obscure file which has (somehow, much in the way you described) "leaped" from system to system to system for hundreds of years ...
The files from the 80s floppies have timestamps in 1999, so they were only a bit over ten years old back when I copied them off the floppies.
I did test some of the floppies in later years and still seemed to work. I still have the floppies but no longer have a working 5.25" drive to try them on!
i have a bunch of NeXT stuff on my backups somewhere, but the oldest files with a legitimate timestamp are from a backup of the G.R.E.A.T. Desktop environment from 1995.
from the README:
G.R.E.A.T Version 0.92
GREAT is the Graphical Environment and Desktop for UNIX.
It is developed by the Free Software Assiociation of Germany
with Ruediger and Michaela Merz.
GREAT is a free binary distribution.
Copyright (C) 1993, 1994, 1995 FSAG
this is interesting, because it appears to be the first FOSS Desktop Environment. i used it on my grandmothers computer. unfortunately the sources appear to be lost. i was only able to find this binary release, and because of its historical value i am holding on to it for dear life.
I was negligent at preserving timestamps during previous backups, so the exact age is lost, but my oldest files are MS Works and Word Perfect documents from Windows 3.1 era in the early 90s. Aside from documents, I think the next oldest are mp3 files that I downloaded directly from the internet in '96 (pre-Napster days, back when you could just find websites that offered mp3 downloads directly). The quality is terrible due to aggressive compression so I should probably just delete most or all of them, but at this point they feel like artifacts. There's also a Weezer music video that came with Windows 98 (IIRC) that I still have.
To grandparent post, Buddy Holly might have been on 98, I'm not sure, but was on the 95 CD along with a trailer to the movie "Rob Roy" and a couple other videos. Might have been different across regions, I'm not sure of that either.
99 comments
[ 3.2 ms ] story [ 140 ms ] threadFor the young'uns, "Shirley" is a reference to a cultural phenomenon in the early 80's through early 90's around a line that would go something like this: "Surely it's an operating system file. Yes of course, but don't call me Shirley!" It was started by a popular movie, but became widespread throughout the culture.
Alternatively, it could have been a speech to text accident and I'm reading way too much into it. I choose to disregard that possibility. Shirley you understand.
Airplane (1980)
In any case, astronomy has that beat hands down, as with https://en.wikipedia.org/wiki/Maisie's_Galaxy ("Maisie's Galaxy (also known as CEERS J141946.36+525632.8) is a distant galaxy located at z=11.4 that existed 390 million years after the beginning of the universe.")
“I suspect these new evicted files take advantage of a trick in APFS: as far as I can tell, they consist of the file with its attributes and extended attributes intact and stored locally, but no extents for its data. Thus, when you ask for the file size, it returns the size it would be when downloaded, although the file only takes the space required for its attributes and extended attributes, until it has been downloaded.”
Also (https://developer.apple.com/documentation/technotes/tn3150-g...):
“Check if a file is dataless and then only access it in a safe context. To do the check, call stat or getattrlist and examine if SF_DATALESS is present in stat.st_flags. Be aware that stat and getattrlist both trigger the materialization of any intermediate folders in the file’s path, if they themselves are dataless.”
⇒ doing stat on an entire filesystem will materialize all directories, but not its files.
While even now with the filesystems that support them they're tied to that instance of the filesystem (ie: non-modifiable, unlike Windows), which has always puzzled me given the need to variously restore from backups (or just have an identical copy in a destination) where one would desire such info*.
* When I last looked into this I saw some quite creative workarounds, such as a script loop where for each file to be copied it changed the system clock to the date of the timestamp, so it was recreated in the destination.
so there are 4 different values:
the original time when a file was originally created.
the time when it was first created on this device.
the time when a particular inode was created.
the time when the content of the file was modified.
and you could add more: if the file contains a story, how about the time the original story was written?
or the time the content (and not the metadata, like the exif data of an image) was modified?
there are use cases for each. but of all of them the last modified time is the easiest to reason about.
However it's easy to preserve the date created timestamp during a copy using the native Robocopy utility, among many other methods. It's simply treated as date modified is: modifiable and arbitrary.
This makes restoring from backups sensible. Have a drive that has died? Can do a file-based restore without the need for images and preserve such metadata. Individual file unexpectedly deleted? Restore it and regain the timestamps. The benefit is one has a transferable reference for when files were originally made, even if they lack internal metadata that stores this (such as eg: EXIF for images).
Under Linux, even with its now kernel-based NTFS support, it just adds NTFS-specific data like date creation timestamps as peripheral extended attributes, which Linux file managers broadly don't expose or handle well. While native filesystems like EXT4 which support creation time are impractically limited to unmodifiable date creation timestamps based on their first creation on that particular instance of the filesystem, without hacky and fragile workarounds.
That is despite `touch` being ubiquitous on Linux for modifying date modified timestamps (showing that in practical terms, it's considered similarly arbitrary metadata) which from what I've seen Linux users appear to have no disagreements with about its utility.
As a Windows user who would like to migrate to Linux this aspect makes it frustratingly a non-starter, as even if one uses SMB to access the files (adding its own layer for such compatible metadata, regardless of the underlying filesystem) Linux file managers still don't handle well extended attributes so management for such files under Linux isn't at parity.
[1] https://en.wikipedia.org/wiki/Ghost_goal#/media/File:Ghost_G....
Oh! And some slightly less ancient with original timestamps still on my server home dir (now Raspbian, but from some mixture of SunOS etc)...
% ls -alrt ~/ | more
...fun to see the `.defaults`; i forgot about that one (edit, and i forget now even when/where i came across it)
Outside of that, the oldest file in my home dir is "de01file.cpy" from 1994-01-06, something I saved for reference from my old Job.
In terms of actual timestamp, the oldest I found was "Aug 18 1994", a text file with some notes from a concert that I wrote to send to friends.
-rw-r--r-- 1 uid uid 21714 Aug 18 1994 concert
I did test some of the floppies in later years and still seemed to work. I still have the floppies but no longer have a working 5.25" drive to try them on!
* Castle Wolfenstien for MS-DOS (1983-6-29)
* Lisa OS Source Code (1983-6-29)
* Classic Mac Disks from the Boston Computer Society (1984-12-24)
* Atari 7800 Ms. Pac Man Source Code (1988-12-24)
* Pyroto Mountian BBS files (1990-10-5)
* Jumpman Lives Source Code (1991-04-13)
* Delightful AU sound files and TIFF images from Sun and NeXT systems (1992-2-29)
* Tim Berners-Lee's WWW Browser Source Code for NeXT (1993-6-21)
* C64 Disk Images (1994-6-17)
from the README:
this is interesting, because it appears to be the first FOSS Desktop Environment. i used it on my grandmothers computer. unfortunately the sources appear to be lost. i was only able to find this binary release, and because of its historical value i am holding on to it for dear life.To grandparent post, Buddy Holly might have been on 98, I'm not sure, but was on the 95 CD along with a trailer to the movie "Rob Roy" and a couple other videos. Might have been different across regions, I'm not sure of that either.
archive.org has the iso browseable
https://ia904501.us.archive.org/view_archive.php?archive=/6/...
and search for the FUNSTUFF/VIDEOS folder.
31MB, Cinepak, 320x240, 15fps, audio 8bit @ 11kHz