Victor Chew wrote:
@ady: I have noted all your suggestions.
However, for your suggestions involving modification dates, I won't be adding them to my todo.
Reason is because mod dates can be changed too easily, including something as trivial as changing the file names to uppercase.
This seems to be not consistent with previous releases. Most CABs contain files with the correct modification date, even for files from 2004. CABs that were updated in several stable UBCD versions (with newer versions of the same files) also retained the correct (updated) modification date.
So the "little things" that can change the modification date to something else than the correct one, have appeared in recent development releases of UBCD. This change was not happening before.
About the mentioned case of changing the file names to uppercase.
First, it is absolutely not needed.
Second, the programs are started from menus or command-line. There is no main interest of changing their file names to uppercase (or lowercase or whatever; just leave it as the original producer published it).
Third, the action of changing a file name (completely, partially, or uppercase or whatever) doesn't change the modification date of a file. That only happens if you use a "special method" as you used for ubcd51a2/3, which is also unnecessary.
If you have to
rebuild a CAB with a newer version of the files inside it, and you were to use the same method you have been using for years, the modification date should be again the original, correct one.
My request is to
rebuild those specific CABs without waiting for a new version of the files inside them. If I find more of those archives, I'll post them (I haven't have the time to check them all).
Quote:
If your purpose is to check for changed files, binary checksums IMHO is the only reliable way to do it. And there are no lack of tools and means to help with the task.
You just mentioned the main reason for my request. For a user to compare the files using checksums, there are cases where several layers of expanding archives are needed. It takes time to expand several layers, HDD space, run checksums on many files, make a list of comparison and filter the differences.
(NOTE: I "can't" just use 7-zip to get into several layers and expand only one file. I mean, 7-zip (and other tools) indeed allows this functionality, but expanding only one file or only the last layer is not enough for the full comparison.)
In contrast, if the CAB is as it is suppose to be, many file managers will do the comparison job trustworthy enough. A file manager is capable of comparing file names, dates, file sizes, folder structures... and give either the similarities or the differences.
Having the complete ISO checksum, and running once a security tool on the complete ISO is enough from a security point of view. I am not trying to check the files for security reasons, hence comparing with a file manager is enough.
If the file manager comparison method shows a different CAB (or any file for that matter), I can check *it* so to answer the question "Hmm, What was changed here?" or questions alike. I don't need to fully expand *all* the layers of archives in UBCD and check/compare each and every file.
If a CAB was modified, I use a file manager to explore it, or I expand that specific CAB and compare it to the original file downloaded from the producer of that tool.
By changing the correct modification date, the CABs' checksums change too, making the comparison steps MUCH more complicated and MUCH more time consuming.
How do you think I found the syslinux-related files that were not correctly updated in ubcd51a1? Other versions/programs (like diskcopy for example) that had some version inconsistency, or that had unnecessary files included, were discovered using the modification date as first clue.
For syslinux-related files, the first clue was the modification date. Only after that first clue, I checked the specific checksums, compare files with several different syslinux versions...
Moreover, not all the programs included in UBCD are listed somewhere. And there is no list of the versions included in the development releases of UBCD, other than the first post of each topic (which is not always correct nor complete). So, if I want to confirm the included version of some program, and compare it to the original current download of that program from its producer, the modification dates are, again, my first clue.
If the program is the same, the functions are the same, so there is no "absolutely critical" condition here. But having the correct modification date makes several "jobs" MUCH, MUCH more simple and MUCH, MUCH less time consuming.
By rebuilding
once those CABs I mentioned, all those tasks are simplified for every future release.
Considering that stable versions of UBCD are released not-so-often, having the possibility to fast-check a file version using its modification date simplifies future customizations (or manual updates).