Re: Breaking Antenna (or "Why Gemfeed Timestamps Sometimes Break")

Ben had some trouble with gemfeed.py file timestamps, and they're definitely not the only one.

I used gemfeed.py for my atom feed creation when I started my gemlog, but I ran into the exact same issues as Ben. Since then I've talked to a lot of other people who've had the same problem. It's definitely not something one needs to apologize for; the script, or linux file timestamps, or some combination thereof is simply confusing.

The "problem" is here.

> "[...] the file "creation time" (which in unix is actually the time of last metadata update) will be used [...]"

A linux file has three different timestamps: atime, mtime, and ctime. They mean accessed, modified, aaaand *drumbeat* changed, respectively. That last one is so commonly believed to mean "created" that that's even what I learned in uni.

When I used gemfeed I tried to fix this with the touch command, but that can only change the atime or mtime. The only way I know of to change the ctime of a file is to make a change to its metadata such as permissions, name, or location. If anyone knows of a way to just set the ctime, please share.

But! Now that I look at the gemfeed.py source code I see there's another way:

use the "--mtime" argument to tell the script to use mtime instead of ctime!

Worth a try, and if you use gemfeed.py and find mtime to be a saner default then maybe send a PR?

-- CC0 ew0k, 2022-01-01