ComputerHunter wrote:
Because this is for WIM based pre-reset Longhorn builds. If you look at the official build 5112, it doesn't even use Joliet Unicode filenames. Some of the things might apply to other Longhorn builds but not everything will.
What about 4002? Or that server build? You need to be very precise especially when you write such a long post which consists only about nitpicks of small details.
ComputerHunter wrote:
gus33000 wrote:Showing an example of such wrong parameters would help so people wouldn't do the same "mistakes" (subjective) and not just -t for example. A proof for the fact they're set to the "modification time of the latest file from that release" would also be appreciated as well as the file in question as well with the original file you base such assessment.
Is it not set to the modification of the latest file (install.wim) in almost all of your repacks? Build 4020 is an example.
You haven't replied to my question, so I do not have a proof of where you got that:
1) I changed the timestamps for everything
2) I used the last modified date for everything
ComputerHunter wrote:
I dislike the fact that all of the timestamps are set to be the same as the latest file because some files were created earlier and why would you ruin their timestamps?
You used the right word here, you
dislike it and that is not a mindset to have when we are thinking about preservation, feeling and likings are one thing but you need to stay neutral. Again, it is in your only opinion that the timestamps are ruined.
You also evade the point I have made in my reply above. You are trying to recreate ISOs which you have:
- No proof ever existed
- No proof what so ever if they ever existed they used these timestamps?
so what about stopping making everything an ISO and just letting it be a rar? But of course no one wants a rar, you included. You keep contradicting your intentions from start to finish.
An ISO is meant to be uniform when it's the result of Microsoft build process, and not a manual intervention.
ComputerHunter wrote:
Say I get a copy of Neptune build 5111 and set all timestamps to NT5INF.CAT's timestamp and upload that to the FTP replacing the copy with inconsistent timestamp, will you let me do it?
It's weird how you took once again, an irrelevant example. As I have said in my reply above, which you 50% discarded, Neptune was a set of patched files manually put in on top of Windows 2000 RC2, and is not the result of Microsoft build process as is.
Your justification is therefore not justified and I'm waiting for a new example. You are also saying it was an ISO originally, again, waiting for proof of that.
I am also saddened that you did not provide any example of the other wrong parameters we should not use. We need such a list so we know what you are talking about, and it is important for preservation purposes.
We also lack a full list of releases you judge incorrect, so we once again do not know what you are talking about.
ComputerHunter wrote:
gus33000 wrote:A list of longhorn builds that leaked that are for sure from network shares would be appreciated so we know what shouldn't be changed. This also raises the question of whenever or not you can have 2 different leaks, one from SMB v1 and one from a physical disk, there is as far as I know no way for you to claim a release was 100% based upon a folder dump than a real disk. Again it being an issue would be subject to public debate.
It doesn't really matter where it came from. If it came from a network share and the exact same build was distributed on physical discs, it should be considered as 2 separate releases separated by "(alt)". There is absolutely no evidence which build came from network shares and which came from physical disc since that wasn't documented but according the leakers, most of them were from network shares. Some releases have batch files on the root directory that reference files in the "..\" and "..\sdk" directory and there is no way for that to happen if they were released on physical discs.
You are saying it doesn't matter where it came from, yet, that did matter enough for you when you say that they surely were distributed on physical disks and thus you feel the need to create an ISO. So does it matter or doesn't it matter? You are once again contradicting yourself.
If there is no evidence that they came from network shares, then why do you think the timestamps that aren't uniform are legit to begin with? Proof? explanation? these would be appreciated. If they are from network shares, you can't possibly go full on making an ISO, but by removing half of the rules applying to pressed discs.
It's like if you wanted to make a pizza without the bottom, it wouldn't work, and it's half backed.
According to you do we also need to convert floppy disc images to ISO files then? Because your logic would hint at that (because it apparently doesn't matter where it came from, it must be an ISO).
ComputerHunter wrote:
gus33000 wrote:I find it extremely unlikely a file can have exactly the compilation timestamp in the PE header on the target filesystem considering Microsoft's build.exe compiler not only outputs all binaries in a binary output folder and not directly to the setup media and Longhorn IBS setups had to be manually made from box standard i386 medium that we all know and loved over the years which again, could have completely different timestamps all-together.
Timestamps in the COFF header are just corroborating evidence. It won't be exactly the same and I totally agree with you but they generally won't be hours and day apart as seen in your repacked ISOs.
You do realize all new builds are one day off, do you?
ComputerHunter wrote:
gus33000 wrote:You take the example here of a disk which doesn't have auto CRC and was clearly not a standard media Microsoft cd building script would output, but the act of someone manually having to do it. I do not understand how this could be relevant in the context of discs output from Microsoft build process as a result. Moreover you say they do not have AutoCRC, then why do you suggest us to use AutoCRC, there's a missing explanation here or a mistake I think, at least it's very confusing and you have a conflicting statement for AutoCRC already.
There is no AutoCRC and the timestamps are inconsistent. There should be an AutoCRC added to those rebuilt ISOs because AutoCRC could be used to verify the integrity of ISOs and they were from folder dumps so doesn't really matter. What all I am telling through this particular disc is that there are official discs without the -t parameter and most Longhorn builds are meant to be distributed through network shares or other means so it is very unlikely for Microsoft to touch the timestamps for something not released on discs. If you want to argue that those came from actual discs, my example will prove that it is possible for official releases to have inconsistent timestamps. I never intended to use this as an argument for AutoCRC so don't get me wrong.
Once again, you evade the context of my reply.
You are taking the example of a disc manually done by an employee and not from Microsoft build script. Your argument is invalidated right from the start because we are talking about you saying physical discs surely existed, because you want to make them an ISO and as if it was out of Microsoft hands.
Have you ever seen winbuilds in your life? I would think no, and it is quite apparent, timestamps always differ between built ISOs and winbuilds.
May I ask why do you keep wanting to make ISO files like if they were out of MS themselves but also exclude half of what original ISOs from Microsoft build script have? Because once again, I do not see any legit example from you.
ComputerHunter wrote:
gus33000 wrote:Again, Neptune isn't a clean build from Microsoft CD building script in their source tree, it is a set of different files applied on top of Windows 2000 RC2, bad example. And this topic was already discussed in one of your other threads. irrelevant to the matter for me.
Unless we have more concrete examples; to me there's 0 example from you confirming your theory already.
Let me re-word this... You think Neptune 5111 was from network shares, right? If so, why don't you rebuild an ISO with all timestamps set to NT5INF.CAT's timestamp like what you have done to all those Longhorn builds? If you are telling me that the timestamps from Neptune build 5111 are original proven by files inside DRIVER.CAB, I can tell you that timestamps from those Longhorn builds could be verified by files inside install.wim.
Again, you are not taking the example of a disc that came out of Microsoft own build script, but was the result of manual modifications of a Windows 2000 RC2 disc. Your argument is still invalid. Please provide a good example and then we will discuss that case.
ComputerHunter wrote:
gus33000 wrote:Again, what you say here is that a file never gets its timestamp modified from MS and you claim this as a fact. There's multiple ways Microsoft can themselves update a timestamp, one of them can also be a simple file transfer over SMB. I do agree timestamps do help, but if you want to go that way why not preserving as well:
- Original leak date from the day it got copied at MS (how would you know?)
- Leaker identify information including national id number
- The network path of such folder that got copied
.. I mean you can't always preserve everything on earth, preserving binaries is already 99% of it done, timestamps are a nice extra, and a commodity, not a requirement for preservation. not to mention that in many cases you cannot preserve timestamps for example:
- Digital games where the download server won't return you the timestamps
- Encrypted digital games from Microsoft etc...
Also keep in mind the timestamps you may see may just be when the file arrived, an hour or two later on the share, it can't be bound to the compile date, especially when disks at the time weren't all SSDs (didn't exist) and took a while to get created on disk. Again unlikely things.
What all you are saying is the cases where timestamps can't be preserved, in that case, an RAR without timestamps will do. What I am talking about is timestamps that are most likely original and there are proofs that they are original.
You are willing to create an ISO, not a rar archive, and as a matter of fact we have 0 release out of Microsoft own build scripts not using the same timestamps for all files. Again, feel free to provide valid examples.
And you are still saying that the timestamps are original, we still see no proof.
ComputerHunter wrote:
If those timestamps are from the time those files arrived, they are still worth preserving since they still tell a story. I don't think that is the case from those builds I have looked at so far. Timestamps != compile date to be honest, the only reflect roughly when it was compiled or last modified which we don't really want to throw away.
Then why do you suggest to get rid of RAR timestamps? They don't tell a story in that case as well? Again, what you want is preserving timestamps and making a high quality ISO out of it like if Microsoft made it. I'm sorry to tell you this but both of these are incompatible with each other unless proven otherwise.
ComputerHunter wrote:
gus33000 wrote:You say you understand that there is no gray area between original and unoriginal. But yet you seem to say you don't? Again a clear contradiction, and right in the same paragraph, then why do you say so at the beginning? I see no value in saying something when you disagree with it right in the next sentence.
I personally disagree, there's original and not original, and you can't have better, that doesn't exist, it's like saying you can have a middle ground between yellow and green, hard to believe or imagine.
So by your logic, no releases should ever be replaced. Rebuilding an ISO made by UltraISO will not make it any closer to original therefore better. Repacking a release with LFN and -j1 will not make it original therefore serves no purpose.
Lets use some numbers instead of colors... Say nothing is 0, original is 1 and all numbers including decimals below 1 are considered as unoriginal (so 0.9999999... is unoriginal). The originality or completeness of an unoriginal release is lets say x. x will never reach one but we want x to be close to 1, don't we? How does it get closer? By having more stuff fixed and making it look more authentic. We can make it approach 1 but it won't ever be 1 and there is no gap between 1 and numbers below 1 since numbers we are talking about are continuous. Original is something to approach but as long as it is not original, it is considered unoriginal. I don't get how "more original" or "better" would sit in the gray area since they are still unoriginal. It can get closer to what it was intended to be but as long as it never reaches that non-existent hash of the original release, it is not original. I think of "more original" or "better" as some aspects from the original release added to the unoriginal release to make it reflect the original release more while staying unoriginal. If you think that nothing could be made "more original" or "better" since those phrases shouldn't exist, then we should stop repacking releases and put those original leaks up.
Where did I say no release shouldn't be replaced? I'm merely pointing out issues in the thoughts you express here.
Again, looking authentic is not only subjective, but you also apply a lot of exceptions into your thoughts, which again, we have no proof that ISOsfrom Microsoft from their build process happened to not use uniform timestamps. So I'll be willing to listen to your explanation and accept it only if the basis of your analysis is founded, which right now, it is not.
ComputerHunter wrote:
gus33000 wrote:Keep in mind Microsoft was not set on what disc format to use during Longhorn development, as a result it is very well possible for you to end up with various parameters combinations for many things (See 4074 with UUIDREF and UDF). You can't really claim that all builds must be the same based on a single ISO you managed to get and look at.
I have my doubts about 4074 since it came from BetasIRC or WiNBETA and uses CDIMAGE 2.52 which was compiled after that release.
So how do you explain UUIDREF? Because by the looks of it it must not be an issue in your thoughts at all, and you will not be open to discussion over the fact your choices may very well be wrong, and if they are, this will ruin the preservation of files.
You are ready to ruin a perfectly fine release just because you have doubts?
ComputerHunter wrote:
gus33000 wrote:There is no direct correlation between file timestamps in a wim (which is a container of an installed system) and the disc media itself. Please provide evidence if there's one, but I don't see any. I do not think you can base with 100% certitude timestamp changes over files copied to a container. In fact just look at recent windows builds, you will see setup files in boot.wim Windows Setup index do not match the setup disc. This decision seems invalid to me.
Imagine there is a file with the same name and hash are present both inside and outside a WIM file and their timestamps are the same. If that is the case, would you say that timestamp is not original? Timestamps outside of WIM files can change easily but timestamps inside the WIM won't. Remember our chat regarding that Neptune build? If the timestamp of a file is same as the timestamp of the same file inside an archive, would you say it is not original?
Once again, you take up the example of neptune
and it is not the result of microsoft build process
Also it's very easy for timestamps to differ inside a wim and outside, and if you don't think it is, I encourage you to read Microsoft WIM format specification and/or try a few things with dism or wimlib-imagex
ComputerHunter wrote:
I get your point that they might not be the same due to many reasons but if the timestamps matches exactly, it is a solid proof that the timestamps outside is now original. To clear up some confusion, I nave make those timestamps up, I only add or subtract offsets to undo all the damage done by packing and daylight saving.
What tells you daylight saving and packing is actual damage, and that it wasn't like this at Microsoft? Proof?
ComputerHunter wrote:
gus33000 wrote:Again I'm sorry, but I have the same argument and talk as above. It is extremely unlikely considering the era hardware and considering many different factors that the files must have the same timestamps as the PE header. Moreover how would you know if this doesn't have an offset built in or a timezone applied? There's no way to tell.
I have said this before, it is fine for them not to be the same but if they do match, it is a corroborating evidence for time timestamps being original. The timestamp inside COFF header should be the number of seconds passed after 1970 and it should be in UTC for everything with timezone applied. If you are building Longhorn in DOS or Windows 3.x, it might not be the case since they use local time.
If it was fine then why are you obsessed with changing timestamps and """fixing them""""?
You are also saying exceptions do exist, so there is doubts with your decision already. We can't really do anything based on doubts.
ComputerHunter wrote:
gus33000 wrote:It would have been appreciated to have command samples for all of these as it would help. But I have a few issues with these decisions, which I explained in detail above, but now I'll bring the rest
Command samples? Don't you already know all the documented commands? You have a script for building ISOs so I don't think it is going to be a problem.
You are making a post for
The community not me. The community needs to know and it is very important for preservation. What if I die?
ComputerHunter wrote:
gus33000 wrote:One issue with your choices alone will sadly be (for you) 4074. The leaked WinHec 2004 4074 release ISO is deemed original because of the presence of the UUIDREF metadata specifically added by Microsoft to vouch for the authenticity of their ISO as well as their provenance. This ISO file (and the amd64 one) use UDF. This clashes with what you're saying here in a big way, and only confirms what i and other said about Microsoft experimenting with different cd format.
I do disagree with you on that since it was built by CDIMAGE 2.52 compiled months after 4074 was compiled. Also, I can embed an UUIDREF, you can embed an UUIDREF and everybody can so I don't know why having UUIDREF proves it original. It could simply be UUIDREF extracted from the original ISOs added to some crappy rebuilt ISOs.
And what? Microsoft can very well make the ISO file after it's compiled no? It's not impossible for them to use a newer cd image to begin with if it happens to be the latest one.
If you can embed an UUIDREF then what doesn't tell you some malicious person (ie me) didn't purposely make timestamps not uniform to begin with, basing them on binary compile time with a very short millisecond offset, just to fool people?
We can go really far with hexediting and conspiracies if needed.
ComputerHunter wrote:
gus33000 wrote:You also try to make an ISO out of what you certainly admit to be folder dumps from their SMB v1 share, but... that's not original either. If anything that should be preserved and the closest to original (even if that doesn't exist is a folder dump by itself. AutoCRC? Ok fair but does it really matter? Did MS always use AutoCRC? Why would you use AutoCRC, do we really know for sure if an iso was made from any build it was made with AutoCRC? You cannot in my opinion generalize decisions based on other different pieces of software, as there's really no way to tell what should have been done, and you'll most likely cause more damage than if you did not bother.
AutoCRC is only used for checking the integrity of a rebuilt ISO for something from folder dumps. I have no problem with all files dumped into an archive but we need ISO to make it easier to install. You know they are from network shares and I am more than happy to know the reasons why you have used AutoCRC.
Can you provide such an example of an official Microsoft ISO rebuilt from a folder dump by Microsoft? And proof of this claim?
You want to make an ISO to make it easier to install, but is that really what you are doing here? Your reply and this thread seems to hint you are doing it for more "originality" (subjective) and not for making people's life easier.
ComputerHunter wrote:
gus33000 wrote:People may not care about timestamps according to you, and maybe that is true, I have not made a poll so I can't claim that with accuracy, but I can assure you people actually do care when people like you and I try to modify a release (hence why I stopped and I did the bare minimum) as you will inflict damage no matter what, and you have no way to vouch for originality in any case. I'm ready to agree with you, but the issues i pointed out would have the merit of being explained, and proven otherwise or confirmed for us to agree.
May I ask a question before I provide you with an answer? Why have you changed all the timestamps so the are exactly the same? Doesn't that inflict damage? It is like using uniform timestamps for Neptune 5111 and since you are saying that I change my stance all the time, why have you changed your stance here? Again, sorry if this sounds rude and no bad intentions here.
Once again, 5112 isn't a valid example...
And still currently we got 0 example of a proper ISO from Microsoft build process of the time which doesn't use uniform timestamps.
May I also bring the subject of 4051 or 4033 ia64? Both of which are fine.
Again, list of things you think I changed along with proof would be appreciated, because even I do not remember which one I exactly changed and it would help fix them if the issues you point out turn out to be validated by an argument.
ComputerHunter wrote:
Now, I will provide my response regarding your question. I think the bare minimum is to change nothing except for correcting aspects that are clearly unoriginal yet still repairable. I do provide evidence every time I fix something but they are simply ignored. I base everything off the original leak which sometimes are gone for good (I do have some original leaks of Longhorn builds saved to my hard drive back in the old days). If you fix something, throw away the original leak without putting a documentation of changes, it inflicts more damage than rebuilding the original leak, provide evidence for changes and write a full documentation including everything changed since it was leaked.
That's what you are doing as well no? You are replacing all ISOs that ever existed on earth with subjectively "better" ISOs in your opinion. Don't you think that's also destructive? You are doing exactly the same thing.
ComputerHunter wrote:
If you want to talk about damage done, changing all timestamps to be the same does more damage than adding and subtracting offsets.
There is no gray area between more or less damage, damage is damage, no way around it. But the usage of the word damage is highly subjective, especially when it is founded on arguments without concrete proof (5111 isn't valid and I'll reiterate that claim).
I will add to this extremely long reply that you are complaining about timestamps, which is a file metadata and is not as important as the files inside the medium. You are trying to deal with files where there is no authenticity of their originality to begin with. All releases are not marked as original. To me, and maybe for others, all this effort and argumentation is actually not useful.
I don't mind though that I took the time to reply to you. We just hope you realize that your efforts, aren't really useful because of the very nature of these files.
Edit: I'm also going to stop replying because I have expressed my opinion and arguments on this matter, and I do not think the OP will change my opinion.