I am having issues when I use eSata from my host machine to the write blocker (Firewire and USB work fine). Basically, the drive (regardless of source- IDE or SATA) will appear to be written to. However, upon reconnecting the source it is back to it's original state. Hashing shows that nothing is being changed either (even if I delete and add files to this mysterious Windows 7 'cache'). So, it is ultimately write blocking, sans the read only warnings I get with Firewire or USB.
Anyone else having this problem while using the eSata port on this write blocker and Windows 7? I have replicated this on another machine and seperate write blocker as well.
I am having issues when I use eSata from my host machine to the write blocker (Firewire and USB work fine). Basically, the drive (regardless of source- IDE or SATA) will appear to be written to. However, upon reconnecting the source it is back to it's original state. Hashing shows that nothing is being changed either (even if I delete and add files to this mysterious Windows 7 'cache'). So, it is ultimately write blocking, sans the read only warnings I get with Firewire or USB.
Anyone else having this problem while using the eSata port on this write blocker and Windows 7? I have replicated this on another machine and seperate write blocker as well.
Check your DIP switches. Refer to the manual or check out the options
Tableau says it is not a bug it is a feature. However strange it seems it works fine.
This is the behaviour I would have expected. There's nothing wrong as such.
Tableau says it is not a bug it is a feature. However strange it seems it works fine.
Hilarious- a 'feature'. Anyway, same results in Linux. My forensic machines are Dell so I haven't found a way to switch between native and legacy SATA (I know that setting may have something to do with this behavior as well).
Regarding the DIPs- could be the issue. However, Firewire and USB all show read only and work as one would expect. It is the eSata that causes this cache or storage in RAM. I'll take a look at these tomorrow out of curiosity.
My Issue was similar but different. Using eSATA, I recevied a different HASH value everytime I hashed the drive. I would write to the drive and it would show the writes taking place. Then, if I power cycled the drive, the writes I made disappeared, as they should, but then I got a different has value.
I rehashed the drive with FW800 and got the original HASH from several months prior, when I used a different brand hardware WB.
I changed eSATA ports. Then I got two matching hash values, but they weren't the true has value. I changed cables with no change in results.
I bought a PCI-e eSATA card and put it into my forensic machine. Then using the same cable in the expansion card, I finally got the correct result.
I was using a Gigabyte X58A-UD3R MOBO with on-board USB/eSATA combo ports. Those two ports were seemingly the problem.
Interesting. I have tested this numerous times and it doesn't actually write to the drive itself regardless of the operating system (so my hashes remained the same). Must be a motherboard chip set problem since you narrowed it down to the ports.
I think this is Windows 7. I tried to move files from one pc to a laptop over a wireless network (both windows 7). The laptop was turned off, but the main PC thought the files had been written, and even showed a valid updated directory. Sounds very similar to what you are reporting.
I think this is Windows 7. I tried to move files from one pc to a laptop over a wireless network (both windows 7). The laptop was turned off, but the main PC thought the files had been written, and even showed a valid updated directory. Sounds very similar to what you are reporting.
mscotgrove, if you scroll further up I mention this outcome is duplicative in Linux. The operating systems I haven't tried this on are XP or OS X.
It's just a caching function of the operating system, there's no problem as such. Use you usual tests to check the integrity of the write-blocker if you need peace of mind.