Opened 18 years ago

Closed 3 years ago

#7502 closed feature request (wontfix)

ALL: Check for presence and validity of external data files

Reported by: SF/clemty Owned by: sev-
Priority: normal Component: --Other--
Version: Keywords:
Cc: Game:

Description

- damaged scummvm datafiles prevent games from playing - scummvm gives only cryptic information when the datafiles are damaged

after running into a similar problem with sky.cpt, I think joostp added a size check which would complain if the datafile was not present in its entirety - maybe add that to ScummVM as well?

here's the problem with kyra on the forum http://forums.scummvm.org/viewtopic.php?t=1784&highlight=

Ticket imported from: #1520433. Ticket imported from: feature-requests/318.

Change History (14)

comment:1 by SF/clemty, 18 years ago

Owner: set to lordhoto

comment:2 by fingolfin, 18 years ago

Definitely sounds like a good idea. We should do that for all the external data files, i.e.

kyra.dat lure.dat queen.tbl sky.cpt

We should first check for the presence of the file, and if missing, show an approriate error *dialog*. Next, run some simply integrity check on the files (minimal file size, a fixed header, whatever), and if that fails, display *another* dialog, telling that the data file is likely corrupt. And ideally, a third dialog would be shown if the data file was outdated.

comment:3 by fingolfin, 18 years ago

Summary: kyra: check size of kyra.datALL: Check for presence and validity of external data files

comment:4 by sev-, 18 years ago

data file structure:

TAG VER LENGTH data block MD5

I.e.: 1. Check TAG that file is valid 2. Check version 3. Check LENGTH 4. Calculate MD5 and match

This will be easy to implement and will be universal enough to avoid any hardcoded file details.

comment:5 by SF/clemty, 18 years ago

wouldn't that require an update to all data files?

I think lordhoto once mentioned that kyra.dat is the same format as the kyra .pak files

comment:6 by sev-, 18 years ago

Yes, but that will be done only once and will save us from these periodic bogus bugreports.

comment:7 by lordhoto, 18 years ago

Owner: lordhoto removed

comment:8 by lordhoto, 18 years ago

The current Kyrandia implementation hardcodes the size in the ScummVM sourcecode, if someones implements the described 'data file structure' in a generic way I'll change the Kyrandia code to support it. I'm changing the 'Assigned To' field to None for now, since I'm not working on a generic way, so any other developer can feel free to implement it and as I, said before, will change the Kyrandia code then.

comment:9 by lordhoto, 18 years ago

I would use a structure like this though: TAG \ (maybe this field could be engine depended too) VER | Datafile header SIZE | MD5 /

DATAFILE > Engine specific stuff

I don't see much sense behind adding the MD5 at the file end.

comment:10 by vinterstum, 18 years ago

We could also preserve at least some measure of backwards compatability by trying to load the file as the old format if it fails the integrity check, and just display a 'Your copy of kyra.dat may be outdated or corrupted' message (given that the current format of kyra.dat would use invalid fields for the integrity check, and always fail it).

It doesn't really make sense to force people to download a new version of kyra.dat for an integrity check when they know their current one works fine :).

comment:11 by SF/clemty, 18 years ago

maybe simply add a size-check for now, add the more sophisticated check the next time kyra.dat changes (or if it is stable, with the next stable version?)

comment:12 by lordhoto, 18 years ago

Clemmy: we have that size check by now.

We should just try to load kyra.dat/otherdatafile in the old style way if just the TAG check failed, we should add a return value in the loading function which tells what failed while trying to load it the new way IMHO.

comment:13 by digitall, 5 years ago

Component: --Other--

comment:14 by sev-, 3 years ago

Owner: set to sev-
Resolution: wontfix
Status: newclosed

Closing this as wonntfix. However, there are thoughts on implementing a full data validity check, perhaps at some point.

Note: See TracTickets for help on using tickets.