Victor,

I don't mean to continue with the modification date discussion (as I already said, it's in your hands), but I do want to point out some FACTS.

_Download original zip;
_Extract it;
_Build the CAB archive;
_Copy/Move it to its final location;
_Run the script to build fdubcd.iso.gz;
_Run the script to build ubcd*.iso.

All those steps are NOT changing the modification date of the original files inside the CAB. So the scripts available to the users are not changing the modification date of the original files.

Besides those steps, an additional FACT, contrary to what you are saying, is that NOT "any simple" operation can change the modification date of a file. Some simple operations can change the "access" date, but NOT the "modification" date.

Those are facts.

Searching for "some" tool that “accidentally” is changing modification dates in your system "might" be time consuming. But contrary to your logic that it wouldn't be worth, I would arrive to the opposite conclusion, independently of UBCD.

If something would be changing "modification" dates (not "access" dates) in my system, and this is not intentionally done by me (I don't have real control of it), and I don't even know what exactly is actually causing this changes? I would certainly try to find out what's going on. The minimum I would do is try my best to at least know what is going on in my system that I don't have total control of it. If, after knowing, I can correct it to make it work as I want, then that's even better.

To change modification dates you either open and save a file, or you use special tools/commands. No “simple” operation would change the “modification” date.

My conclusion would be different than yours, and that's fine. That's different from a fact.

If you can avoid/minimize this type of changes in the future, it would make it easier for users to manually update or customize, and to find potential updates.

Thank you.

Miray HDClone 4.0.6 was released.

@IceCube, ady:

Added to todo. Thanks!

Just to show you how simple the modification date can be inadvertently changed, try this:

From Windows, double-click any ZIP file and open it using Windows' own built-in ZIP viewer. Pick any file within the archive and note the mod date. Drag-and-drop the file to a temp directory and check the mod date of the extracted file. Let me know if they are the same.

Note that this is built-in Windows stuff. Now extrapolate that to the 100s and 1000s of third party tools out there.

Of course, they are also third party tools that lets you change the mod date to anything you like: example.

Usually I expand the complete zip using Windows Explorer. As I already wrote twice, expanding the latest astra.zip (as example) and building the CAB, and using the regular scripts to build ubcd, gave me the same mod date of the original files.

Now I just tried what you said, to expand only one file from the zip using drag and drop from Windows Explorer. I checked the mod date of the only one expanded file. You know what? Once again the mod date was the same as the original. No change.

I tried expanding only one file (using drag and drop as you requested) from a ZIP, and also from a CAB, both times using built-in Windows Explorer capabilities. No change.

You may use different methods. The only thing that, maybe, just maybe, could "accidentally" change the mod date in these simple steps, is if you are using a "conversion" utility, so to "convert" a full ZIP archive into a CAB, for example.

The other way, in this context, that can change the mod date is by using a "binary" script, as you might have used to change some files from lowercase to uppercase while still inside the archive (as oppose to expanding, then changing the names and rebuilding the archive anew). This is not the case of astra.



Well, I just tried the built-in Windows Explorer stuff and there is no change. Is there any need to try more equivalent tools?



Yes, and I know several more of those tools. I could also customize UBCD with the correct mod dates, but that's not the point, at all. In fact, downloading your original ubcd, and then customize it with the same programs just to change the modification dates would be pointless. So, in this context, what would be the point of using (or having to use) those type of tools?

I still can't see any step that should lead you to changing the mod dates of the same original files, and I still see only positive results and advantages of using the original modification files in the future.

So I'll repeat my request:

If you can avoid/minimize this type of changes in the future, it would make it easier for users to manually update or customize, and to find potential updates.

Thank you.

Miray HDShredder 3.8.1. is available so to update the next UBCD.

Hardware Detection Tool current stable release is 0.5.0 http://www.hdt-project.org/

@manicmind: HDT has been updated to V0.5.0 since 5.1a3.

HDT will soon be v0.5.1:
http://syslinux.zytor.com/archives/2011 ... 16717.html

_________________
Download Ultimate Boot CD v5.0: http://www.ultimatebootcd.com/download.html
Use Parted Magic for handling all partitioning task: http://partedmagic.com/

Miray DiskCheck 4.0.6 was released.

ubcd51b1 -> ubcd -> tools -> linux -> ubcd2usb -> readme.txt.

The latest change:



starts with 2 consecutive <tab> instead of a sequence of spaces, which might lead the reader to accidentally skip that important step.

Replace 7za.exe with 7zdec.exe (v 9.22) in the FreeDOS floppy image:
http://www.ibiblio.org/pub/micro/pc-stu ... DEC922.ZIP

We only need to be able to extract 7z files in FreeDOS (at least that is what we need in the floppy image itself, the full 7za.exe could still be added as a program archive, if necessary).

7zdec.ex is 65kb versus +/- 500 kb for 7za.exe. So we get a lot of free space back.

_________________
Download Ultimate Boot CD v5.0: http://www.ultimatebootcd.com/download.html
Use Parted Magic for handling all partitioning task: http://partedmagic.com/

There might be a little problem with this change.

7za.exe is used in (or called from) some batch files inside



In some instructions, you would need to "add" 7zdec. In some instructions you would need to "replace" 7za.exe and put instead 7zdec.exe.

So, first you need to rename 7zdec922.exe to 7zdec.exe, so the batch files won't need to be changed again if you update the exe in the future with a different version number.

Second, apparently the command is:

But according to the batch files included in fdubcd.img, there are more arguments needed to use with 7za.exe in addition to those above.

If 7zdec922.exe doesn't conform to those additional arguments, then 7za.exe can't be replaced by 7zdec922.exe. I don't know the answer to this .

Seems like what ady said is correct.

7zdec cannot function as a drop-in replacement for 7za because it is lacking quite a few switches that 7za provides. It will require non-trivial modifications to the batch files.

For documentation sake, I am going to repost IceCube's PM to me about 7zdec here:

I did investigate the suggestion above, and here's what I found.

1) As it is, 7za.exe can be removed without adverse effect from FDUBCD because there are no ZIP or 7Z archives within the fdubcd.img, only CAB files. I can't remember why 7za.exe was included in the first place, when other archiver supported by UNPACK.BAT and RUNAPP.BAT such as uharcd.exe and unrar.exe are not. Any idea?

2) 7za.exe supports both 7Z and ZIP formats, and RUNAPP.BAT use 7za.exe to decompress both formats. If this is to be maintained, then a DOS version of unzip.exe will need to be included, and the batch files tweaked to reflect this change.

3) 7zdec.exe does not support an output path parameter, which apparently is supported by the other archivers and used to that effect (note the %dest% argument):



This can probably be overcome by finding some DOS independent way of doing pushd/popd (FreeDOS has this, but not MS-DOS for example), which I haven't looked at.

So...

If we want to save the maximum amount of space, I think we should just remove 7za.exe. This seems to make the most sense to me because all archive files in fdubcd.iso are CABs anyway.

Well, as mentioned in several places, including the customization tutorial, several types of archives are "compatible" with fdubcd.img (myapp.cab, myapp.zip, myapp.7z at least). 7za.exe is the one "providing" all those other possibilities besides CABs (or was also for CABs too?; I don't remember right know).

The reason the default archives are "CABs" is very simple: Victor prepares them , and their compression is excellent. But let's face it; CAB is not the most popular format, even under Windows. (Don't get me wrong, CAB is a great type of archive to use in UBCD, and I use it myself too, but it is not *that* popular).

Moreover, I don't know (yet) of any tool that can create CABs under Linux for example (the list at http://www.ultimatebootcd.com/forums/viewtopic.php?f=8&t=2706 under Linux currently includes tools only capable of extraction, not creation from CABs).

I also think (but I may be wrong) that all those arguments and extra parameters / switches in the batch files for 7za.exe are meant to support several different situations, including other archive types.

Now, would you want to throw away compatibility with different types of archives? That's only going to limit the users in customization.

In addition, less and less users are capable of "reading" a DOS-based batch file. That means less possibilities to test, find problems, and improve. If changes are made in the FDUBCD batch files, they have to be tested. And if, for some reason, any user (or Victor) in the future wants to get back any function that would be lost by the changes in those batch files, then it would be much difficult to re-program.

Those are "cons" of getting rid of 7za.exe. And the "pros": free space in FDUBCD.IMG, and "maybe" more free RAM. Do we need that free space now? Is any user in need of that free space? Aren't there any alternatives?

If we need more free space, there are more alternatives. If we know of some specific improvement (whether adding a new function, a new program, or more free RAM needed under DOS), then let's open a topic for discussion. Until then, I don't think getting rid of 7za.exe is a good idea (unless a better alternative program is capable of fully replace the complete current capabilities).

Of course, that's only my humble opinion.