Backup Fails With Pre Unix Epoch Timestamp
cwarden opened this issue · 2 comments
This file causes a panic while running a backup:
-rw-r--r-- 17 root root 213K Dec 31 1969 /path/to/SVI_0001.JPG
fileHasKnownData panics with "CHECK constraint failed: files" because of the constraint on the files table, CHECK(fs_modified >= 0).
I can recreate the table without the constraint, but perhaps that constraint should be reconsidered, or better error reporting should be added since there's no indication of which file failed or why.
I think you recreating that table might be best. I would have to add a new layer to db/schema.go to rewrite the entire files table without that constraint. I think a negative last modified timestamp is wild. Perhaps a fork/branch of gb could be made where every call to .ModTime() on os.FileInfo can be negated if already negative? Dec 31 1969 probably means a modtime of -1 which can just be changed to 0. Your modtime is garbage data anyway - I assume the file was not TRULY last modified then? If I were you I'd just write a script to update those modtimes from -1 to 0 :)
Leaving the issue open because you're right that gb should at least fail more gracefully in this case though.