jaclaz

... some say only on wednesdays, and if there is a full moon ... jaclaz

Good. Out of the dowload of grub4dos: http://grub4dos.chenall.net/downloads/grub4dos-0.4.5c-2016-01-18/ http://dl.grub4dos.chenall.net/grub4dos-0.4.5c-2016-01-18.7z you need only grub.exe. And out of the download of grubutils: https://code.google.com/archive/p/grubutils/downloads?page=2 https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/grubutils/grubutils-2011-06-27.zip you need only the "fat" file. General usage is here: https://www.rmprepusb.com/tutorials/grubutils#TOC-fat what you need to do (on grub4dos command line) is: root <- should give (fd0) as feedback insmod /fat fat mkfile size=51200 (fd0)/mysectors.bin dd if=(hd0)0+100 of=(fd0)/mysectors.bin bs=512 count=100 If you already made a new file 51200 bytes or larger on the floppy via DOS or any other means you can of course avoid the grubutils download and usage of the "fat" commands. jaclaz

It could be an issue with either the boot code (in the PBR) or with some data (again in the PBR, i.e. in the BPB or Bios Parameter Block). If I recall correctly, when grub4dos chainloads directly io.sys, it recreates the BPB data "on the fly" using the data found in the partition table. Clearly the partition table is fine (since the volume can be booted and DIR, etc, works just fine) and also most of the BPB must be "good enough" for exactly the same reasons. Is the volume FAT16 or FAT32? If the latter the situation is a bit more complex as the bootsector is spanned over three sectors. I need to see: 1) the MBR, i.e. sector LBA 0 2) the PBR, i.e either sector LBA 63 or sectors LBA 63-65 Basically, you should make a copy of first 100 sectors of the hard disk, compress the file into a .zip archive and upload the archive to some free hosting site or attach it to your next post, Now the issue is how exactly to extract these 100 sectors from DOS. How much available space do you have available on the boot diskette? You need 100*512=51,200 bytes ( the space for the 100 sectors) + the space for the program to dump them[1]. The 0.4.5c version of grub4dos (not the 0.4.4) does have a built-in dd command that would do (as long as you have any means to create an empty file 51.200 bytes in size on the floppy), otherwise we could actually use the (experimental) fat library for grub4dos. Try using the recommended 0.4.5c version of grub.exe, if it works it will be the easiest way to make the dump of the needed sectors. jaclaz [1] it's a lot of time I don't deal with "pure" DOS, I have not in mind a program capable of doing this in "pure" DOS and small enough to fit in a diskette, in the good ol' times DEBUG scripts were used, but it is some of the knowlefge that has been lost over the years, I cannot remember right now any suitable "pure" DOS tool

Provided that the hard disk is actually around 640 GB in size (or to be more exact it had a single partition of around 640 GB), DMDE actually found *something*. The 975 MB or around 1.02 GB in size image is too small to be meaningful (on any NTFS filesystem bigger than 5 or 6 GB the $MFT is placed on cluster 786432, which equates to roughly 3 GB). You can try "going on", selecting "$Noname 01" and then clicking on "Open Volume" but since no $MFT is available, your only option would be "file based" recovery (which is only good for files that were "contiguous"). A functional 640 GB or so hard disk should take (ddrescue is AFAICR an "average" speedwiseprogram) a few hours to be imaged, approximately between 2 and 4. So if you got 1 GB in 1/2 hour, imaging the whole disk would probably take more than 300 hours , which while not entirely unheard of: https://www.forensicfocus.com/Forums/viewtopic/t=11313/ poses a SERIOUS problem on the integrity of the disk. You need to make sure, d@mn sure, that the disk does not overheat, usually a fan (or more than one) are used to keep the disk "cool" when doing this kind of imaging that results in so many errors. But maybe it is the case of attempting to use a (if not better) more tweakable tool, that would be dd_rescue (and dd_rhelp): http://www.garloff.de/kurt/linux/ddrescue/ or ddrescue (and ddrutility): https://www.gnu.org/software/ddrescue/ddrescue.html (Linux only) Still, there remains a risk that by these attempts the situation worsens, so - once again - I have to ask you to consider whether your data/photos are worth (or are not worth) the possible cost of a professional data recovery service, if you continue there is a concrete possibility that if you later change your mind, the data/disk would be further degraded and thus made unrecoverable (the professiona that will make this later attempt, no matter what was the real cause will anywyay blame your attempts for the unrecoverability of the data). jaclaz

If via grub4dos it boots, then the system is just fine. Once you are in grub4dos (press "c" to get the grub4dos command prompt) there are THREE ways to boot the DOS/Win98 #1 chainloading the system file bypassing BOTH the MBR and the PBR (what is in the grub4dos "standard" menu.lst): find --set-root /io.sys chainloader /io.sys boot (the "boot" is NEEDED on command line and IMPLIED in a menu.lst entry). #2 chainloading the PBR of the volume, bypassing the MBR : find --set-root /io.sys chainloader +1 boot #3 chainloading the MBR: rootnoverify (hd0) chainloader +1 boot Doing the three tests above you will be able to check which part is "defective" and we will see how to "fix" it. SYS is an external command in DOS, so you need to copy it (SYS.COM) to the boot floppy if it isn't there for *whatever* reason. Please check (and double check) that the boot floppy (and the SYS.COM) come from the exact same version of DOS/Windows9x. jaclaz

... and I thought I was the one that would have failed in a diplomatic career ... jaclaz

You can try to not looking at the screen , and/or start saying aloud "I am not going to work with this computer today, it seems like a perfect day for a walk outside" or similar, maybe it works like boiling water for tea http://www.gutenberg.org/ebooks/308 http://www.gutenberg.org/files/308/308-h/308-h.htm and it decreases the amount of memory in use ... jaclaz

No, it isn't, or, if you prefer, it only happens on the vast majority of systems, but not necessarily on all of them. The booting PE has been documented to in some cases to detect disks in a different order from BIOS, and of course another number of factors may be involved, like the exact way the disk is partitioned (before or during the install) and the exact way the OS is installed (via normal setup, third party automated tools, dism apply, etc., etc.). Since it costs nothing at install times to disconnect the "other" disks it represent a foolproof way to make sure it doesn't happen. jaclaz

Let's try to clear the matter. Calling *anything* RAID without specifying its RAID level makes NO SENSE WHATSOEVER. RAID 0 is NOT properly "RAID" as there is NO redundancy whatsoever, it is only a senseless way to (maybe) achieve very slight read/write speed increases (which actually happened only on some given configurations making use of slow, now obsolete, devices and connection buses) at the (real) cost of a definite increase in the risk of failure. RAID 1 is actually "RAID", BUT it should be called simply "disk mirroring". You can have disk mirroring BOTH via hardware and via software, in the case of Windows, software disk mirroring is one among the modes "dynamic disks" can be setup. BUT at the end of the day, since the disks are actually mirrored, there are very little differences in practice on the contents of disks. Basically each disk is (or should be) an exact mirror of the other. In ordinary, day to day operations, you will notice no differences using the one or the other. When (if) disaster strikes and one of the two disks in a "mirrored" set fails, there are only a few slight differences, not really worth more than a thought. In the case of a "hardware" mirrored set of two disks, you can *any time* take the one (or the other) and connect it to another PC and it will be immediately recognized as a "normal", "self standing" disk, and you will be able to access its contents "normally". In the case of a "software" mirrored set of two disks, when you take the one (or the other) and connect it to another PC it won't be recognized "as is" and you will need to change the partition ID in the MBR from 42 to 07[1], and then it will be recognized as a "normal", "self standing" disk, and you will be able to access its contents "normally", even if a few sectors at the end of the disk (outside the normally accessed area) will contain "dynamic disk" settings data). The "hardware" mirrored set might be (slightly, you won't probably notice it) faster in operation. Of course the "software" and "hardware" mirrored set settings "do not communicate" as - even if the end result is the same or very nearly the same - the way they work is different. With hardware, you are essentially saying to the hard disk controller to write the data it receives to two different devices, with the software you are telling to the Operating System to write the data to two different connected devices. Personally if I were to choose, I would prefer a hardware mirrored set (aka RAID 1) over Dynamic Disks anytime, only because Dynamic Disks have historically given more problems, though the reason is not clear/straightforward, a possibility is that knowledgeable people (and with the available means to buy more costly hardware) chose either hardware mirroring or never chose "RAID 1" while a vast number of less knowledgeable people (and/or without the means to buy a RAID controller) chose the "free" Dynamic Disks mirroring, hence there are very few reports of issues with hardware RAID 1 and some more with "Dynamic Disks". jaclaz [1] Never tried/checked how these disk behave if GPT and not MBR, but most probably there will be a similar issue of chainging partition ID.

If the files can be seen by dir and you already fid a fdisk /MBR the only remaining thing is making sure that: 1) the partition is Primary and Active 2) the bootsector of the partition conatins valid code 3) the IO.SYS and other system files are actually there What I would do: 1) make a dos/Windows 98 boot disk with a copy of grub.exe (the grub4dos DOS executable) or make a grub4dos boot floppy (or USB stick/CD/whatever) 2) run grub4dos 3) attempt to boot the Windows 98 system on the disk by directly chainloading the system file This more otr less equates (on the grub4dos command line) to find how the disk is seen in the BIOS (it will be either (hd0) or (hd1)) and which is the partition where the DOS/Win98 is (normally first partition, i.e. either (hd0,0) or (hd0,1). So: geometry (hd0) geometry (hd1) if the disk is seen as (hd0) root (hd0,0) ls <- this should show the contents of the partition, like DIR chainloader /io.sys boot if the disk is seen as (hd1): map (hd0) (hd1) map (hd1) (hd0) map --hook root (hd0,0) ls <- this should show the contents of the partition, like DIR chainloader /io.sys boot You can use *almost any* grub4dos version, but I would suggest a 0.4.5c version, like: http://grub4dos.chenall.net/downloads/grub4dos-0.4.5c-2016-01-18/ http://dl.grub4dos.chenall.net/grub4dos-0.4.5c-2016-01-18.7z or, if it doesn't work (the Presario is an old machine and not many tests have been made with newer versions on old machines), a "historical" 0.4.4, last version of it, 2009-10-16 that you can find here: http://reboot.pro/topic/16641-grub4dos/ If you need help assistance in the usage, just post your questions/doubts. jaclaz

Again, not very good signs, actually bad ones. Basically a hard disk sector (which is normally seen as being 512 bytes in size) contains - accessible only by the internal citcuits/logic, a record that is a sort of checksum of the contents of the sector itself, called CRC or Cyclic Redundancy Check, this is a value, written at the time the sector is written that is checked when reading the data to make sure that it is valid. If you have a huge number of such errors, particularly if they come in "a bunch" at cyclical intervals it is likely a (but not necessarily) a failed head. The image won' t be successful, you can stop the imaging of the whole drive. You can or you cannot hear the hard disk "crunching" at intervals? If you stop the program you should still have available the (partial) image (the .dd file). Check it in a hex editor, or in DMDE. Is it all 00's or it does contain some data? All the symptoms till now are that of a failed drive, point is whether some partial data can be copied or not, and if these data are enough to recover (some of) the photos. If your photos have a value I would suggest you to stop fiddling with the disk and ask for the assistance of a professional data recovery firm. Typically we are talking of a cost of anything between US$ 300 and US$ 2000 and there is no guarantee that the photo can be recovered, most "serious" recovery firms (not very easy to find BTW) will ask you anything between US$50 and US$300 to "diagnose" the disk, and then will submit you an estimation of the cost of recovery (id possible). jaclaz

A semi-random thought, but maybe one could try actually disable the volume in HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices\Offline and then mount the volume "indirectly" (and with another drive letter) via IMDISK, that does have a "direct extent access" feature: http://reboot.pro/topic/20450-mounting-split-image/?p=192170 It has to be seen if volsnap.sys actually hooks also this IMDISK volume (that appears not in disk manager, etc. as it is basically a "superfloppy"). jaclaz

Isn't this one good enough? http://www.learnersdictionary.com/definition/spy jaclaz

Sure , I know, hence I explicitly specified "whatever remains of it on an internet connected machine". Now, who is soundings like a conspiracy theorist? Please don't forget a Velostat cap: http://reboot.pro/topic/13177-an-improved-electromagnetical-shielding-device/ you never know ... jaclaz

Not really. A conspiracy theorist would assume that since it is not documented the exact way the data is sent and which exact data is actually sent, then there must be something "evil" behind it. The two statements are instead simply meaning that something is not documented and this may (or may not) be a violation of privacy (whatever remains of it on a internet connected machine ). jaclaz

Good. The issues being : 1) there is NO proof that this happens "anonymously" or "anonymously enough" 2) what is actually sent to MS is NOT adequately, let alone fully, documented 3) in the old way you reported a bug and were regularly ignored, what makes you think that the telemetry data is not also blatantly ignored? (the only good thing is that you don't have anymore to talk with some support rrepresentative attempting to put the blame on you - or read on a board pathetic attempts by totally clueless people) 4) and this is the worst part, the final result will be that we will be ONLY ALLOWED to use our computers in ways conforming to what the good MS guys believe that is better for us based - maybe - on how the majority of other people use their computers. (something between the Pareto principle and Wisdom of the crowd ) jaclaz

Home Basic, you mean? https://en.wikipedia.org/wiki/Windows_Vista_editions Also Starter (x86) is missing. And the K, KN and N editions. jaclaz

Naaah, more like Monty Python's Life of Brian: https://www.imdb.com/title/tt0079470/quotes/qt0471984 jaclaz

To clarify: No doubts about the stern look of disapproval, it's only about the amount of time served, that should be proportional to the delay caused to the project: jaclaz

Well, Rules should be clear, I propose: If it happens, your account will be disabled and the final release will be delayed for long time one period for each infraction. Where period may be 1 day, 1 week, 1 month, etc. Essentially someone wanting to halt the development would: 1) donate a small amount of money 2) download a private build 3) republish it 4) anonymously alert Bigmucle of the "leak" 5) get his/her account banned AND have the final release delayed by one period 6) rinse and repeat Now, it would only be fair that this hypothetical saboteur was made able to calculate the cost of the sabotage, and If the delay is exponential (as opposed to fixed) the saboteur would save a lot of money, Also, how can we adequately blame "nicely" if we don't know how long enough the final release was delayed because of his naughty behaviour? jaclaz

So, the action of one will have consequences for many? Interesting approach, but I was more curious about the "and". Seingly the one's acount has been blocked BUT the final release has not been delayed (or maybe it has been delayed without publicizing the fact). jaclaz

Hmmmm, and what about the red, (bolded by me) part? I simply cannot understand it. jaclaz

Sure. Sometimes form is not substance, but the issue is that we already have a whole bunch of ambiguities in the language, think of disk vs. drive vs. disk drive vs. the thing that gets a drive letter (which is a volume or a partition or both) to which you add some Chinglish, the generally poor quality of documentation (particularly when it comes to "advanced" topics such as Raid and similar) and you understand how - even set aside my built-in pickiness - we must try to be as exact/accurate as possible or however attempt to make things as clear as possible. jaclaz

@dencorso Some say ... https://www.motoringbox.com/stig-quotes/ jaclaz

Yep , the point still being that - like any other similar tool - it may make a forensic sound image of a working or functional disk, and it has to be seen if it does make it as a RAW (or dd) file or it uses any proprietary formats. At first sight I could only find "direct disk cloning" (with the "Forensic Sector Copy") on Macrium Reflect pages (but I do trust your word for it), the issue is only how it behaves with "defective" sectors and similar , some softwares (designed for backup/copy etc. as opposed to those designed for rescue/recovery) tend to fail or hang forever if "bad" sectors are found and (this is a generic note, not specific to Macrium) high-level, evoluted, automagic programs that can do this (and that and that other thing) might be more "sensible" to "bad" data than plain, simple tools that only do one thing are. jaclaz