Tom's Guide | Tom's Hardware | Tom's Games
 |
 |
 |
I need help with the following problem: Using MS cabarc.exe, I create an archive containing several files. Some of those files were last modified over a year ago, and others were last modified only a day ago. When I then use cabarc.exe to extract the files, I've noticed that the "Date Last Modified" property of the files created recently has changed by only one or two seconds. The "Date Last Modified" for the older files does not change at all.
For example, the following two files were added to the archive on 01/22/05:
textfile-1.txt => Date Last Modified = 03/05/04 12:15:22 pm
textfile-2.txt => Date Last Modified = 01/10/05 09:20:10 pmWhen extracted from the archive, I get the following:
textfile-1.txt => Date Last Modified = 03/05/04 12:15:22 pm
textfile-2.txt => Date Last Modified = 01/10/05 09:20:12 pmI know that 1-2 seconds isn't that big a deal for many folks, but it is a really big deal for me because certain software that I have refuses to operate properly when a file's "Date Last Modified" differs coming out of a CAB archive from the "Date Last Modified" going into the archive.
visit :
http://www.febooti.com/products/filetweak/tutorials/tutorial-change-file-dates.html
this software allows you to change the properties.
0 
Sounds like you're smart enough to have thought of this, but does cabarc have command line options or an ini file / script capability?
In both cases, the very recent and the year old, are the files both being added to the CAB with the same compression [or no compression]?
M2
0
Mechanix2Go, thanx for the reply. Yes, both files are being added to the cab archive using the exact same compression - none. From the directory in which cabarc.exe resides, the two files are located in a subdirectory named \Temp. Using the command prompt, I create the cab archive with both files at the same time by typing -
cabarc n archive.cab temp\*.*I then extract both files at the same time to the subdirectory \Temp2 using the following -
cabarc x archive.cab temp2\Using Hex Workshop v2.01, I then open the file 'textfile-2.txt' - both the copy in the \Temp subdirectory and the copy in the \Temp2 subdirectory and do a comparison of the two files. Results: Both files are exactly identical. Still, I don't understand why the date is being changed.
Keep in mind that the 'textfile-2.txt' file is only one of many files being affected like this. The exact same problem is occurring with files in the following extensions (so far): exe, chm, dll, ocx, txt, doc.
I have completely removed cabarc.exe from my system, thinking that it might be virus infected, and removed all references to cabarc.exe from the registry and various files on my computer. I then downloaded the CAB SDK from Microsoft and reinstalled it. The exact same problem exists.
Funny thing, cabarc.exe was working fine on my computer for nearly two years. This problem reared its ugly head only within the past week.
To answer your question, Yes, cabarc has command line options, and No, there is no ini file/script capabilities that I am aware of.
BTW, Thanx for the link Legend. I haven't had the chance to visit it yet. I'm heading there as soon as I complete this post.
Regards,
Roy
0
Hi Roy,
Well, if it didn't affect other file types that would be even more wierd.
If you want, send me a copy and I'll mess with it.
CAB@ThaiGuides.com
M2
0
Thanx M2 for the offer of help. I just sent you a cab by email. I just realized that the exact same problem is occurring when I create ZIP archives using WinZip.
BTW, are you in or from Thailand? Just wondering because of your email address. I just returned from Thailand Dec 28. Was there when the tsunami hit. My wife's from Cholburi and we were there visiting family. If you are from or in Thailand, I hope everything went well for you and your family when the tsunami hit.
Regards,
Roy
0
I made a slight error in a previous post. Using
cabarc n archive.cab temp\*.*
all files in the archive are compressed using MSZIP FORMAT. I also tried using
cabarc -m NONE n archive.cab temp\*.*
which uses no compression, with the same results.
Now, here's something really weird -
I created an archive with one file as follows:
testfile.txt => Date modified = Today, January 23, 2005, 8:06:30 PMI extracted the file and got the following:
testfile.txt => Date modified = Today, January 23, 2005, 8:06:32 PMI took the extracted file and created a new cab archive with it, then extracted the file from the archive and got the following:
testfile.txt => Date modified = Today, January 23, 2005, 8:06:32 PMThis time, the Date modified did not change. I opened the file, saved it and got:
testfile.txt => Date modified = Today, January 23, 2005, 8:12:14 PMI created another archive with the file, then extracted the file and got:
testfile.txt => Date modified = Today, January 23, 2005, 8:12:16 PMI took the extracted file and created yet another new cab archive with it, then extracted the file from the archive and got the following:
testfile.txt => Date modified = Today, January 23, 2005, 8:12:16 PMSo, it looks like the archiving process affects the file's date modified only the first time that they are archived after being created or modified. Pretty weird in my book.
IF FileHasBeenModified AND NOT FileHasBeenArchivedBefore THEN
ChangeDateModified
END IF
AddFileToArchive
0
Very wierd.
I tried with WINZIP and the time stamp did not change.
I'm not familiar with hexWorkshop, but I've got a fileCompare util which is very quick and clean. It's one of those PCMag gems written in assembler. Maybe limited to file size less than 64K, but should be just the thing for this purpose.
Available here:
http://www.golden-triangle.com/COMPARE2.COM
2454 bytes
syntax: compare2 file1 file2 /b
The /b does a binary compare. I think you'll want a binary compare in this case even though these are "text" files, because cabarc may be making a slight alteration; and taking two seconds to do it.
If that turns out to be the case, I don't know what you'd do about it.
If this cabarc.exe is not corrupted and not being tripped up by some other setting or process, surely another SDK user would have encountered this.
M2
0
I downloaded the app you recommended and gave it a try. The results: "are effectively identical" was returned. So, it doesn't look like cabarc is making a change at the binary level in the file.
I ran Hijackthis on my computer and the log came back sparkling clean. I searched through the registry and could not find a single reference to cabarc. Also, the only reference to cabarc within the files on my HD are in the docs that were distributed from MS with the CAB SDK.
I deleted cabarc and winzip from my computer, did a thorough cleaning, then reinstalled them from fresh sources. Still, the problem persists. This problem didn't exist at all until the middle of December, 2004. I just can't figure out what in the world happened to cause this to start.
I've posted this problem on a few boards, including the members area of AstalaVista, and it seems to have everybody stumped.
Thanx for your help.
Roy
0
Usually when the chumps get stumped, it's because the OP has no idea what he's doing and can't follow directions.
This is not a case of that. This is a real tough nut.
It's astonishing that no other SDK users have found this.
Just for drill, you might try with files, let's say, several hours old; several days old; several months old etc to see if there's a clean cut-off. Wouldn't "fix" it but would contribute another scrap of evidence.
Try SET and see if there's any reference in the environment to cabarc.
I guess cabarc.exe is a command line util. Does it need some DLLs or other bits and pieces? VBRUN? VCRT?
You can tell I'm grasping at straws here.
M2
0
I'll give that a try - archiving files from different time periods until I find a time period that is not affected. I'll post again when I have the results.
What is SET? I'm not familiar with that.
Yes, cabarc.exe is a command line util. From what I can see, it does not reference external files such as DLLs, VBRUN, VCRT, or anything else of that nature. I do know that when compression is used, cabarc uses the MSZIP format - but for all I know, the compression routines could be build into the exe internally.
Just to see if it worked, I just ran System Restore on my computer and restored it to December 17 (the earliest restore point available). The problem still existed so I undid the restore.
I guess one of the things that makes this so hard to figure out is that when I send samples of the before-and-after files being modified, the "before" files become the "after" files when added to an archive for emailing, thereby giving nothing as a before picture of the file being modified. Did that make any sense to you??
Well, it's 1:37 am over here. I've been working on this problem all day. Time to get some shut-eye so I can start all over again on it in the morning.
Thanx for your help,
Roy
0
I tried SET and there were no references to cabarc in the environment.
I just copied 40 files from different areas of my computer into a single directory so that I can add them to a cab file. All of these files were created by me, and include the following extensions: xls, jpg, psp, txt, pub, doc, mdb
I created a cab archive with all 40 files, then extracted the files and checked their modified dates against the dates of the files prior to building the archive. Two things were discovered...
1) The problem starts with files created somewhere between 8/21/2004 and 9/29/2004.
2) EVERY file created and modified before the problem start date has a very, very weird similarity in their Modified dates - they all are set with 00 seconds. Out of 40 files selected at random, 29 of them were last modified on or before 8/21/2004, and all 24 of them have 00 in their seconds position. For example:
2004Expenses.xls => Date Modified = Saturday, August 21, 2004, 3:31:00 PM
Budget.doc => Date Modified = Wednesday, May 05, 2004, 4:17:00 PM
logo.psp => Date Modified = Tuesday, March 02, 2004, 5:08:00 PMOkay, is this weird, or what?
Regards,
Roy
0  |
 system talks at boot up!
|
Just-In-Time Debugging (R...
|
This post is quite old and has been locked from receiving new replies. Please create a new posting instead.
| Ads by Google |
