This makes zero sense - part deux
-
It's gonna be one of those days... If you've never heard of [Ventoy](https://www.ventoy.net/en/index.html), it's a utility that lets you boot from a USB thumbdrive, and then presents a menu made up of any number of bootable ISOs you just dump on the drive. You have to format the thumbdrive with it (so it can be made bootable and loads the app that looks for ISOs and builds the menu), but the ISO files themselves aren't touched in any way. So that's besides the point. I just copied an .ISO file on the thumbdrive, stuck it into a laptop, booted from it and started installing the OS...halfway through it, it complained the image wasn't valid. Sure enough, if I compared SHA256 hashes between my original ISO file and the copy I made on the USB stick, they don't match. Easy enough fix, I'll just re-copy the file and be done with it. For good measure, before wasting my time reinstalling, I'll re-compare the hashes. They *still* didn't match. I re-did it a third time, same thing again. The original ISO file is on ComputerA, and the thumbdrive is in a USB port on ComputerB. I'm copying the file across the LAN and directly onto the USB stick. And I consistently get this mismatched hash. So I took the USB stick and plugged it directly into ComputerA, and compared the hashes - they finally match (!)... Why would the extra step of going over the LAN modify the data stream contained within the file? Given I was able to produce an identical copy of the file on the same USB thumbdrive by avoiding the LAN, I can't really blame the drive itself. This isn't the analog world. Any read/write error should've been detected in transit, and reported by the OS. Yet it remains blissfully unaware the target no longer matches the source. How do you even explain that? Additional details: ComputerA is an old system that can only do USB2. ComputerB is newer and the USB stick was hooked up to a USB3 port. Surely the difference in transfer speeds can't blindly introduce errors that get ignored?? Otherwise there's no way I could ever trust a transfer of any kind of binary data...
-
It's gonna be one of those days... If you've never heard of [Ventoy](https://www.ventoy.net/en/index.html), it's a utility that lets you boot from a USB thumbdrive, and then presents a menu made up of any number of bootable ISOs you just dump on the drive. You have to format the thumbdrive with it (so it can be made bootable and loads the app that looks for ISOs and builds the menu), but the ISO files themselves aren't touched in any way. So that's besides the point. I just copied an .ISO file on the thumbdrive, stuck it into a laptop, booted from it and started installing the OS...halfway through it, it complained the image wasn't valid. Sure enough, if I compared SHA256 hashes between my original ISO file and the copy I made on the USB stick, they don't match. Easy enough fix, I'll just re-copy the file and be done with it. For good measure, before wasting my time reinstalling, I'll re-compare the hashes. They *still* didn't match. I re-did it a third time, same thing again. The original ISO file is on ComputerA, and the thumbdrive is in a USB port on ComputerB. I'm copying the file across the LAN and directly onto the USB stick. And I consistently get this mismatched hash. So I took the USB stick and plugged it directly into ComputerA, and compared the hashes - they finally match (!)... Why would the extra step of going over the LAN modify the data stream contained within the file? Given I was able to produce an identical copy of the file on the same USB thumbdrive by avoiding the LAN, I can't really blame the drive itself. This isn't the analog world. Any read/write error should've been detected in transit, and reported by the OS. Yet it remains blissfully unaware the target no longer matches the source. How do you even explain that? Additional details: ComputerA is an old system that can only do USB2. ComputerB is newer and the USB stick was hooked up to a USB3 port. Surely the difference in transfer speeds can't blindly introduce errors that get ignored?? Otherwise there's no way I could ever trust a transfer of any kind of binary data...
I know nothing about hashes for ISO files; but could it be including the timestamp in some form? From one computer to another the hash on the "sent" file won't match the clock (and hence the file write timestamp) on the receiving machine. If you copy directly from HDD to thumb drive all on the same PC, they will. The file content isn't modified, but the file metadata is.
Telegraph marker posts ... nothing to do with IT Phasmid email discussion group ... also nothing to do with IT Beekeeping and honey site ... still nothing to do with IT
-
It's gonna be one of those days... If you've never heard of [Ventoy](https://www.ventoy.net/en/index.html), it's a utility that lets you boot from a USB thumbdrive, and then presents a menu made up of any number of bootable ISOs you just dump on the drive. You have to format the thumbdrive with it (so it can be made bootable and loads the app that looks for ISOs and builds the menu), but the ISO files themselves aren't touched in any way. So that's besides the point. I just copied an .ISO file on the thumbdrive, stuck it into a laptop, booted from it and started installing the OS...halfway through it, it complained the image wasn't valid. Sure enough, if I compared SHA256 hashes between my original ISO file and the copy I made on the USB stick, they don't match. Easy enough fix, I'll just re-copy the file and be done with it. For good measure, before wasting my time reinstalling, I'll re-compare the hashes. They *still* didn't match. I re-did it a third time, same thing again. The original ISO file is on ComputerA, and the thumbdrive is in a USB port on ComputerB. I'm copying the file across the LAN and directly onto the USB stick. And I consistently get this mismatched hash. So I took the USB stick and plugged it directly into ComputerA, and compared the hashes - they finally match (!)... Why would the extra step of going over the LAN modify the data stream contained within the file? Given I was able to produce an identical copy of the file on the same USB thumbdrive by avoiding the LAN, I can't really blame the drive itself. This isn't the analog world. Any read/write error should've been detected in transit, and reported by the OS. Yet it remains blissfully unaware the target no longer matches the source. How do you even explain that? Additional details: ComputerA is an old system that can only do USB2. ComputerB is newer and the USB stick was hooked up to a USB3 port. Surely the difference in transfer speeds can't blindly introduce errors that get ignored?? Otherwise there's no way I could ever trust a transfer of any kind of binary data...
-
It's gonna be one of those days... If you've never heard of [Ventoy](https://www.ventoy.net/en/index.html), it's a utility that lets you boot from a USB thumbdrive, and then presents a menu made up of any number of bootable ISOs you just dump on the drive. You have to format the thumbdrive with it (so it can be made bootable and loads the app that looks for ISOs and builds the menu), but the ISO files themselves aren't touched in any way. So that's besides the point. I just copied an .ISO file on the thumbdrive, stuck it into a laptop, booted from it and started installing the OS...halfway through it, it complained the image wasn't valid. Sure enough, if I compared SHA256 hashes between my original ISO file and the copy I made on the USB stick, they don't match. Easy enough fix, I'll just re-copy the file and be done with it. For good measure, before wasting my time reinstalling, I'll re-compare the hashes. They *still* didn't match. I re-did it a third time, same thing again. The original ISO file is on ComputerA, and the thumbdrive is in a USB port on ComputerB. I'm copying the file across the LAN and directly onto the USB stick. And I consistently get this mismatched hash. So I took the USB stick and plugged it directly into ComputerA, and compared the hashes - they finally match (!)... Why would the extra step of going over the LAN modify the data stream contained within the file? Given I was able to produce an identical copy of the file on the same USB thumbdrive by avoiding the LAN, I can't really blame the drive itself. This isn't the analog world. Any read/write error should've been detected in transit, and reported by the OS. Yet it remains blissfully unaware the target no longer matches the source. How do you even explain that? Additional details: ComputerA is an old system that can only do USB2. ComputerB is newer and the USB stick was hooked up to a USB3 port. Surely the difference in transfer speeds can't blindly introduce errors that get ignored?? Otherwise there's no way I could ever trust a transfer of any kind of binary data...
To add my useless reply, just can't resist :) Some years (15?) ago, had just that happen copying files between two linux servers. The useless part is that I can't remember what the problem was (need to refresh my memory sticks and backups). I seem to remember throwing one of the (somewhat old) servers to the trash as I come to the conclusion (after switching network cards, memory sticks, disks, ...) that the problem was motherboard related. Just a few tests you can do: - redirect the ssh stream to output and sum that to check if the problem is in the network stack or local. - write the file to disk instead of usb and do the sum on the disk file, the problem may be in writing to the usb. - if using wifi try using a network cable - if already using a network cable, try using a new one and(or connecting to a different port on the router/switch. As obermd wrote, I also had no errors anywhere to show that something odd was happening.
-
It's gonna be one of those days... If you've never heard of [Ventoy](https://www.ventoy.net/en/index.html), it's a utility that lets you boot from a USB thumbdrive, and then presents a menu made up of any number of bootable ISOs you just dump on the drive. You have to format the thumbdrive with it (so it can be made bootable and loads the app that looks for ISOs and builds the menu), but the ISO files themselves aren't touched in any way. So that's besides the point. I just copied an .ISO file on the thumbdrive, stuck it into a laptop, booted from it and started installing the OS...halfway through it, it complained the image wasn't valid. Sure enough, if I compared SHA256 hashes between my original ISO file and the copy I made on the USB stick, they don't match. Easy enough fix, I'll just re-copy the file and be done with it. For good measure, before wasting my time reinstalling, I'll re-compare the hashes. They *still* didn't match. I re-did it a third time, same thing again. The original ISO file is on ComputerA, and the thumbdrive is in a USB port on ComputerB. I'm copying the file across the LAN and directly onto the USB stick. And I consistently get this mismatched hash. So I took the USB stick and plugged it directly into ComputerA, and compared the hashes - they finally match (!)... Why would the extra step of going over the LAN modify the data stream contained within the file? Given I was able to produce an identical copy of the file on the same USB thumbdrive by avoiding the LAN, I can't really blame the drive itself. This isn't the analog world. Any read/write error should've been detected in transit, and reported by the OS. Yet it remains blissfully unaware the target no longer matches the source. How do you even explain that? Additional details: ComputerA is an old system that can only do USB2. ComputerB is newer and the USB stick was hooked up to a USB3 port. Surely the difference in transfer speeds can't blindly introduce errors that get ignored?? Otherwise there's no way I could ever trust a transfer of any kind of binary data...
Check for updates on your network and USB device drivers. TLDR Flew across the pond on a support call… Your app crashes on startup. Bring my desktop CPU (with app source, debugger, etc) all the way to customer site. Fire up the app, no issues. Client starts app on their system and it crashes. Client is hosting the app on a network share. Copy the app to the local hard drive and it works. It turns out there was a bug in their network driver. They updated the network driver and then it would load from the share.
-
It's gonna be one of those days... If you've never heard of [Ventoy](https://www.ventoy.net/en/index.html), it's a utility that lets you boot from a USB thumbdrive, and then presents a menu made up of any number of bootable ISOs you just dump on the drive. You have to format the thumbdrive with it (so it can be made bootable and loads the app that looks for ISOs and builds the menu), but the ISO files themselves aren't touched in any way. So that's besides the point. I just copied an .ISO file on the thumbdrive, stuck it into a laptop, booted from it and started installing the OS...halfway through it, it complained the image wasn't valid. Sure enough, if I compared SHA256 hashes between my original ISO file and the copy I made on the USB stick, they don't match. Easy enough fix, I'll just re-copy the file and be done with it. For good measure, before wasting my time reinstalling, I'll re-compare the hashes. They *still* didn't match. I re-did it a third time, same thing again. The original ISO file is on ComputerA, and the thumbdrive is in a USB port on ComputerB. I'm copying the file across the LAN and directly onto the USB stick. And I consistently get this mismatched hash. So I took the USB stick and plugged it directly into ComputerA, and compared the hashes - they finally match (!)... Why would the extra step of going over the LAN modify the data stream contained within the file? Given I was able to produce an identical copy of the file on the same USB thumbdrive by avoiding the LAN, I can't really blame the drive itself. This isn't the analog world. Any read/write error should've been detected in transit, and reported by the OS. Yet it remains blissfully unaware the target no longer matches the source. How do you even explain that? Additional details: ComputerA is an old system that can only do USB2. ComputerB is newer and the USB stick was hooked up to a USB3 port. Surely the difference in transfer speeds can't blindly introduce errors that get ignored?? Otherwise there's no way I could ever trust a transfer of any kind of binary data...
dandy72 wrote:
So I took the USB stick and plugged it directly into ComputerA, and compared the hashes - they finally match (!)...
Presumably this was after you recopied the ISO to the USB again right?
dandy72 wrote:
Any read/write error should've been detected in transit, and reported by the OS.
Really depends on how it was transferred. Dropped packets happen more times than you'd think. If the mechanism you're using to transfer files uses UDP underneath the hood, then there is no error checking for packets.
Jeremy Falcon
-
It's gonna be one of those days... If you've never heard of [Ventoy](https://www.ventoy.net/en/index.html), it's a utility that lets you boot from a USB thumbdrive, and then presents a menu made up of any number of bootable ISOs you just dump on the drive. You have to format the thumbdrive with it (so it can be made bootable and loads the app that looks for ISOs and builds the menu), but the ISO files themselves aren't touched in any way. So that's besides the point. I just copied an .ISO file on the thumbdrive, stuck it into a laptop, booted from it and started installing the OS...halfway through it, it complained the image wasn't valid. Sure enough, if I compared SHA256 hashes between my original ISO file and the copy I made on the USB stick, they don't match. Easy enough fix, I'll just re-copy the file and be done with it. For good measure, before wasting my time reinstalling, I'll re-compare the hashes. They *still* didn't match. I re-did it a third time, same thing again. The original ISO file is on ComputerA, and the thumbdrive is in a USB port on ComputerB. I'm copying the file across the LAN and directly onto the USB stick. And I consistently get this mismatched hash. So I took the USB stick and plugged it directly into ComputerA, and compared the hashes - they finally match (!)... Why would the extra step of going over the LAN modify the data stream contained within the file? Given I was able to produce an identical copy of the file on the same USB thumbdrive by avoiding the LAN, I can't really blame the drive itself. This isn't the analog world. Any read/write error should've been detected in transit, and reported by the OS. Yet it remains blissfully unaware the target no longer matches the source. How do you even explain that? Additional details: ComputerA is an old system that can only do USB2. ComputerB is newer and the USB stick was hooked up to a USB3 port. Surely the difference in transfer speeds can't blindly introduce errors that get ignored?? Otherwise there's no way I could ever trust a transfer of any kind of binary data...
dandy72 wrote:
Otherwise there's no way I could ever trust a transfer of any kind of binary data..
Imagine, a surgeon if you will. Explaining all this high-tech they have to assure you, and you see a VB6 interface on one of the monitors? "Trust"? Well, it goes as far as I can throw a brick, and that's literally so. Trust means complacency, so by default, there shouldn't be any.
Bastard Programmer from Hell :suss: "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
-
Check for updates on your network and USB device drivers. TLDR Flew across the pond on a support call… Your app crashes on startup. Bring my desktop CPU (with app source, debugger, etc) all the way to customer site. Fire up the app, no issues. Client starts app on their system and it crashes. Client is hosting the app on a network share. Copy the app to the local hard drive and it works. It turns out there was a bug in their network driver. They updated the network driver and then it would load from the share.
-
What about introducing a new four-letter abbreviation: TMDC. Too Messy, Didn't Comprehend.
-
I know nothing about hashes for ISO files; but could it be including the timestamp in some form? From one computer to another the hash on the "sent" file won't match the clock (and hence the file write timestamp) on the receiving machine. If you copy directly from HDD to thumb drive all on the same PC, they will. The file content isn't modified, but the file metadata is.
Telegraph marker posts ... nothing to do with IT Phasmid email discussion group ... also nothing to do with IT Beekeeping and honey site ... still nothing to do with IT
-
I've seen this on other large files. For some reason SMB copies across networks can glitch. I suspect it's a bug in the Windows SMB implementation that only manifests on network links.
I'm inclined to believe this...however this would mean I'd end up with tons of corrupt files. The backups I create from my NAS are done across my LAN, and I have no inclination to believe any file has ever been corrupt in that way. But now you have me worried :-)
-
To add my useless reply, just can't resist :) Some years (15?) ago, had just that happen copying files between two linux servers. The useless part is that I can't remember what the problem was (need to refresh my memory sticks and backups). I seem to remember throwing one of the (somewhat old) servers to the trash as I come to the conclusion (after switching network cards, memory sticks, disks, ...) that the problem was motherboard related. Just a few tests you can do: - redirect the ssh stream to output and sum that to check if the problem is in the network stack or local. - write the file to disk instead of usb and do the sum on the disk file, the problem may be in writing to the usb. - if using wifi try using a network cable - if already using a network cable, try using a new one and(or connecting to a different port on the router/switch. As obermd wrote, I also had no errors anywhere to show that something odd was happening.
-
dandy72 wrote:
So I took the USB stick and plugged it directly into ComputerA, and compared the hashes - they finally match (!)...
Presumably this was after you recopied the ISO to the USB again right?
dandy72 wrote:
Any read/write error should've been detected in transit, and reported by the OS.
Really depends on how it was transferred. Dropped packets happen more times than you'd think. If the mechanism you're using to transfer files uses UDP underneath the hood, then there is no error checking for packets.
Jeremy Falcon
Jeremy Falcon wrote:
Presumably this was after you recopied the ISO to the USB again right?
The original file sitting on ComputerA's hard disk, which I know has a valid hash.
Jeremy Falcon wrote:
Dropped packets happen more times than you'd think. If the mechanism you're using to transfer files uses UDP underneath the hood, then there is no error checking for packets.
Copied the file by dragging/dropping with Windows Explorer. You'd *hope* it wouldn't use a protocol that allows packets to be dropped silently...