reyalp
If it's going be at the root level, I'd prefer to have the name be less generic. It could be CHDKMETA or HDKMETA even if it's shared with with other CHDK derived hacks.
I'm OK with CHDKMETA (or _HDKMETA perhaps?), although I'm not sure DSLR hack guys would be very happy about it.
Or if it's just one file, just put CHDKMETA.JSN in the root or something.
You're out of date 😀 There are currently proposals for three files, namely:
SOFTWARE.JSN to indicate the installed software
CAMERA.JSN to indicate the detected camera (cannot be reliably produced during CHDK build)
MODEL.JSN to indicate the selected camera (applies to the N/N Facebook case)
There is one
additional proposal that's too high level to discuss ATM.
Indeed so, but this is true whether the directory goes in the root or not. Any software that relies on this would need to be prepared to find the directory in either or both partitions, possibly with different versions or not matching the actual binary.
My current code:
[tt] private void CopyPrimaryFiles(string srcPath, string destPath)
{
CopyFiles(srcPath, destPath);
var srcMetadataPath = Path.Combine(srcPath, "METADATA");
CopyDirectory(srcMetadataPath, destPath);
}
private void CopySecondaryFiles(string srcPath, string destPath)
{
foreach (var dir in Directory.EnumerateDirectories(srcPath))
{
var dirName = Path.GetFileName(dir);
if (!"METADATA".Equals(dirName, StringComparison.InvariantCultureIgnoreCase))
{
CopyDirectory(dir, destPath);
}
}
}[/tt]
I believe metadata belongs with the binary, so if present, it must be on the primary partition (at least).
I would be strongly against using a directory used/managed by the Canon firmware.
I can see why, although I can also relate to the notion of keeping a memory card as tidy as possible (did I mention OCD already?). I just found out about the MISC directory, which seems to be created by newer DSLRs, and I find it even more compelling (since it's top-level).
* Implementing all this all this for one utility that may not be maintained in the long term. Zeno's endorsement helps with this one 😉
As far as client software is concerned, software metadata is of little use beyond the update scenario. I believe STICK and ASSIST are pretty much feature-complete, although I might be mistaken here.
* It's easy for the meta information to get out of sync with whats actually installed. Is it actually helpful if it's not reliable?
If the metadata is bundled, it requires a special effort on the user's part to mess it up.
If it's generated by a client software, that has to be really bad to either mess it up programmatically or cause the user to do that at a later stage 😀
In any case, I think the worst-case scenario is the latest version being needlessly reinstalled (unless of course someone installs SDM onto a card while leaving the metadata intact).
We could probably append minimal version info unencrypted to the end of DISKBOOT.BIN. It would be loaded and turned to garbage by the diskboot process, but this should be harmless, and wouldn't take memory at runtime. It would ensure that you can get the actual version of the binary, rather than an external file which can get out of sync.
Here's a list of ideas upon deciphering dancingbits, in ascending order of insanity:
- De-dance the binary after matching a magic bit sequence
- De-dance the binary in all flavors (up to VITALY times)
- Match a known binary hash (obtained from every binary ever built)
Compared to that, the idea of an unencrypted metadata block sounds great, although I'm not sure why it should be favored over the JSON proposal, other than the latter's being significantly harder to implement (although I am biased).
Edit 2017-04-24: Redacted.
