Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Panic on attempt to serialize a pre-epoch timestamp received from an ext3 filesystem #464
While working on a tool to index files for one of my projects, I wound up getting a panic during the call to
I tracked it down to a specific file in my home media server. Apparently, the combination of Linux and the ext3 filesystem is perfectly capable of representing at least one date before the UNIX epoch.
...and the irony is, SystemTime is the one piece of the Rust-provided metadata that I felt was already in a format suitable for a generic index file to be shared between programs written in different languages.
Well... that and it was a hassle to track down because Rust itself didn't complain and the panic message during serialization wouldn't tell me which file of the hundreds of thousands was causing it to die. For lack of a purpose-built tool, I had to manually bisect it until I narrowed it down.
referenced this issue
Jul 17, 2018
...and I found another one:
(Yes, my folder structure for stuff bound for archival DVDs is an accreted mess that needs to be refactored.)
UPDATE: It appears that this example only fails because of integer overflow on
The relevant portion of the backtrace:
The code in question:
The issue is, there's no official way to get the underlying value out of
This should probably be filed as an issue against the standard library; there needs to be some way to extract the underlying value of
It should still be possible to work around it. I'll try to verify it later today, but, as I remember, the
That's how an mtime of
(In other words, the output is semantically equivalent to a
That said, definitely a footgun in the standard library to be remedied.
referenced this issue
Jul 19, 2018
Yep, I figured that out after writing the previous comment, and started working on a patch to serde to fix it.
My main concern is that
So I think you'd have to do it without
I think that you'll just have to use an
Hmm. Good point.
I have no problem with being clamped to a little over 292 billion years from the epoch for positive range, but I really would like to avoid this being another non-obvious location where someone who wants high reliability has to guard against failure.
Would it be a breaking change to switch to
I think it will always be a breaking change, as some formats may never support
I also think that it might be a breaking change to change the type at all, since the
On the other hand, it might be argued that you're replacing a very likely panic on serialization with a less likely properly returned error on deserialization only in the case of two different programs using different versions of Serde. I don't know if Serde has a stability policy for the types used for serializing
Of course, one alternative is that you could just use a newtype wrapper and implement
My main concern here is getting rid of the footgun if at all possible. I really don't want to have to maintain a special "Never allow these types to creep into structs I'm deriving Serialize/Deserialize on, because the compiler certainly won't warn you" audit list.
I've already spent more time trying to get comfortable with the Serde docs for customizing deserialization of complex data than on the rest of the project put together, so I think I'll just go for pragmatism over perfection, spend 5 minutes to manually convert
Then I can move on to hacking up a quick implementation of my "Use