jaclaz

I don't understand. You haven't been able to test a 2 Gb or 8 Gb because you have not any handy. OR You have been able to test a 2 gb and a 8 Gb BUT they did not work 100% correctly. OR You decided to NOT test a 2 Gb and a 8 Gb (though you would have been able to test them) because you believe they won't work correctly jaclaz

What do you mean? If you found the actual files (and you need them) you copy them to a new volume. If you want to repair the filesystem on the single image you use CHKDSK, after having found and corrected manually the errors (if any) that you found through analysis of the image. jaclaz

Anybody else think that problems could (needlessly) arise from this attempt to put everyone on the same "version" of Windows? ... I suppose we might be able to rely on the version number (6.x.yyy.zzz), but that would introduce a cumbersome additional step into the discussion. And I'm not sure what it would help, anyway -- maybe you installed a June update but not the April one, for example. Don' t tell the MS marketing guys, but IMNSHO this (continuously updating a codebase) is what the engineers have done since 2006 (actually before since 2000). In their own definition, there is a major and minor version of the OS. NT 4.00 was 4 Windows 2000 was 5.0 Windows XP was 5.1 Server 2003 was 5.2 (and also XP 64 bit, which is actually a dumbed down version of Server 2003) Those were the early "version 5" operating systems. Vista was 6.0 7 was 6.1 8 was 6.2 8.1 is 6.3 These are the current "version 6" operating systems. jaclaz

A classical example on how to use a "right" tool for the "wrong" scope. jaclaz

@TELVM How queer, there was a recent article on Redmond Magazine had these (triumphant) news: http://redmondmag.com/articles/2014/09/15/windows-8-surpasses-windows-xp.aspx I do understand how this "OS share" numbers can have little variations/fluctuations, but I find surprising that XP is today: http://www.winbeta.org/news/windows-8-and-windows-81-see-drop-their-market-share-windows-7-continues-gain-momentum at 23.87% and that 15 days ago it was only 12.9%: http://redmondmag.com/articles/2014/09/15/windows-8-surpasses-windows-xp.aspx I guess that based on these data we could publish an article titled : jaclaz

You see, how different perspective can be? I would be happy about that as it could be a sign that the reply came from an actual human being (though not informed or misinformed or however providing a non-answer or an answer to a question that was not asked) as opposed to an automatic copy-paste-reply program. jaclaz

Good or bad is - as always - in the eyes of the beholder. The thing that can be said for sure is that it won't be timely. They are talking of talking about it (besides hopefully troubleshooting/debugging/whatever) until end of April 2015 to which it is easy to add 3 to 4 months for putting together and deliver the RTM, then possibly another couple ones for "general availability", i.e. almost one year from now. This would mean almost 3 years, i.e. longer than what they took to create Vista SP3 Windows 7. I guess that everyone that has not yet jumped on the 8/8.1 bandwagon will keep - if at all possible - clinging to their XP or Vista or 7 for one year more (please read as "I predict a very slow increase in 8/8.1 adoption in the next months"). jaclaz

Well, Windows IX would have been cool IMHO. jaclaz

Well, you either have some confused sources or you are confused by the terminology (which can be confusing). Vista uses BOOTMGR which is both a bootloader and a bootmanager. XP uses NTLDR which is both a bootloader and a bootmanager. These files won't be changed (not corrupted) at install, but the bootsector code that load the one or the other will. As well, the configuration file for Vista which is \boot\BCD would normally be automatically updated to include an entry for a "previous" XP install. The normal booting of Vista is: BIOS->MBR->PBR of active partition->BOOTMGR->Choices in \boot\BCD->Winload.exe->Windows Vista The normal booting of XP is: BIOS->MBR->PBR of active partition->NTLDR->Choices in \BOOT.INI->NTDETECT.COM->Windows XP The normal booting of Vista and XP in dual boot (when VIsta is installed AFTER the XP is: BIOS->MBR->PBR of active partition->BOOTMGR->Choices in \boot\BCD->Winload.exe->Windows Vista BIOS->MBR->PBR of active partition->BOOTMGR->Choices in \boot\BCD->NTLDR->NTDETECT.COM->Windows XP So there are three key changes to observe. When the Vista is installed after XP it will: change the MBR code (but this won't have any effect unless the existing MBR is one of the special ones allowing for a recovery partition) change the PBR code (that will now invoke BOOTMGR instead of NTLDR add to the \boot\BCD an entry for loading the WIndows XP When the XP is installed after Vista it will: change the MBR code (but this won't have any effect unless the existing MBR is one of the special ones allowing for a recovery partition) change the PBR code (that will now invoke NTLDR instead of BOOTMGR)So, the "right" way to add an XP to an already Vista installed system is: backup the "Vista" MBR backup the "Vista" PBR install the XP boot to the XP backup the "XP" MBR (you never know) backup the "XP" MBR (you never know) restore the "Vista" MBR and PBR reboot to Vista add to the Vista \boot\BCD an entry to boot the XPThere are several ways to perform the above, if you have a bootable Vista DVD, (though I recommend anyway to backup both XP and Vista MBR and PBR) you can use it to perform #7-9 (I believe that the XP install would be added to \boot\BCD automatically, but I may be wrong but in any case you can use bcdedit to add the entry). To backup and restore the MBR and PBR sectors you can use *any* disk editor or a dd like program, or the GUI Hdhacker: http://dimio.altervista.org/eng/ You can also alternatively use the built-in in Vista bootsect.exe to change the PBR code (the Vista version of bootsect.exe won't change the MBR code) and MBRFIX: http://www.sysint.no/nedlasting/mbrfix.htm These latter will simply write the XP or Vista Code to the MBR and PBR (leaving the data untouched). jaclaz

How surprising. How surprising. How surprising. (would that make a "How surprising3"? About the misspelling, IF your name is Eric and Jitin wrote Erik instead it's not IMHO that much an issue, on the other hand, if your name is Jean-Philippe it would sound preoccupying... jaclaz

Perfect. : jaclaz

Maybe something like this: PLEASE READ POST #2 needs to be added to post #1 jaclaz

And possibly fmg stands for Flavio M. Gomes . I doubt that many people on MSFN can read (or appreciate) Portuguese , exception made for Dencorso , obviously. Be aware of Rule #2e however : http://www.msfn.org/board/index.php?app=forums&module=extras&section=boardrules jaclaz

Yep , I would also like Julie Larson-Green and Terry Myerson to come here and explain the MS standpoint on the matter. jaclaz

Well, then it's OK, it is the RAID sector (the data in the MBR is about CHS 8/0/1 whilst the LBA is 8 sectors), either is a "peculiarity" of the RAID setup or the disk has been partitioned with a third party tool. However, the "main" volume is the one corresponding to line: which is also seemingly in "good shape" (at least when it comes to "primary" descriptors) as you have the EBCF in green. http://dmde.com/manual/partitions.html You should select that line and then click on "Open volume", the other ones are "false positives". jaclaz

jaclaz

No. In the sense that I strongly doubt that a NTFS filesystem can be found on 8th sector on a hard disk like device. Normally the VBR of first volume on any partitioned device is (depending on the disk setup/partitioning tool used and under which OS) is normally at offset 63 sectors (before Vista) and at offset 2048 sectors (Vista and later). Are you sure about this "8th sector"? Are you sure you provided the disks in th eright order (or that they were identified properly)? Do you have now a non striped image? Check the first sector of the image (or first sector of both devices). It should be normally a MBR (even if GPT, it would have a "protective" MBR entry). You can access the device or image with DMDE, you should have a situation similar to the screenshot attached (IF the MBR data is still valid). jaclaz

Can you name the people you contacted? jaclaz

The RAID 0 is the most basically form of multi device striping. If you have a (very small) filesystem that is made of 8 blocks (in this case blocks the size of the striping, not necessarily the device block size), you will have on a "normal" single disk blocks arranged as: 1st disk 1-2-3-4-5-4-7-8 When you create a Raid 0 you "stripe" the filesystem on two disks, and you will have: 1st disk 1-3-5-7 2nd disk 2-4-6-8 A destriped image is the result of taking the blocks alternatively from the two devices and arranging them as they would have been on a single disk: Image: 1-2-3-4-5-6-7-8 In "normal" operation of the OS the RAID 0 (be it a hardware raid or a software one) is "transparent" to the user, but when it comes to data recovery, the tool in use may access the device(s) directly or however using algorithms that are not compatible with a non-sequential/multi-device arrangement. If you prefer, once the two devices in a Raid0 have been destriped into a single image, the recovery process is exactly the same if there was not a Raid0, but rather a "normal" single disk/volume. The reasons why *any* filesystem may fail can be mainly caused by: hardware failure <- which can be due to any of the two SSD involved malfunctioning or to one of the two channels to which they are attached (just as an example think what would happen if one of the two cables connecting the devices has a "false contact" software failure <- which can be due both to an issue with a Mass Storage driver in the OS or to an incorrect filesystem driver or to a "wrong" write operation caused by *any* malfunctioning software running in it or even to an issue of some kind in the firmware (please read as BIOS) in the case of a "hardware" RAIDOnce you have accessed a device (or in your case a couple of devices) in DMDE, you do a "scan" to find which (parts of) filesystems it can find, each and every disk image that was saved as "RAW" (or as VMDK or as VHD/VHDX) on the original volume will be found (DMDE has no way to know it is an image and not a partition/volume). It is your duty to find (since it was a single partition volume, from the info you posted, it will be easy) which volume is the "previous one" and select it for further analysis (the volume will be in your case the one which starts first and ends last, i.e. the one with biggest extents). Depending on the actual reason why the corruption occurred and to the specific corruption that occurred (i.e. which areas of the filesystem were affected and how large are the affected areas) recovering a corrupted filesystem can be easy or downright impossible, no way to know in advance. Then again, even if the filesystem is unrecoverable, single files in it may be either fully recoverable (contiguous files) or only partially recoverable or unrecoverable. DMDE is a very powerful tool but it implies (besides studying attentively it's manual/help file) an underlying knowledge of the filesystem that you are going to attempt recovering. jaclaz

The two SSD's (if setup in RAID) can only have been RAID 0 (which is not strictly speaking a RAID level) or in RAID 1. You need to know how it was setup earlier, if you had the two 120 Gb set up in order that combined they made a 240 Gb device, you have Raid 0 (which is a setting for "speed only" as it provides no redundancy whatsoever). I don't think that Gparted (and not even testdisk) are suitable tools to recover a striped in RAID 0 setup. You need a specific tool (or do it manually): http://www.freeraidrecovery.com/library/raid0-recovery.aspx to find the parameters of the Raid and hopefully recover the data that can be recovered. I don't think that there are freeware tools for raid recovery (but I may well be wrong) apart the mentioned one: http://www.freeraidrecovery.com/library/data-recovery-vs-raid-recovery.aspx and DMDE: http://dmde.com/ http://dmde.com/manual/raids.html I am personally very partial to DMDE, which I find an exceptionally good tool, but it is NOT an "automated" or "automagic" kind of tool. Otherwise, you may try using the former to create a destriped image and then you will be able to run (say) Testdisk, CHKDSK on the image to attempt recovering the filesystem and, should this not be possible, attempt recovering the files (photorec and similar). jaclaz

It sounds a lot like recent Microsoft attitude . Seriously, maybe you are in a "early adopter" group. I don't think that there is much experience around for that kind of setup, though experiments into that (or something similar) has been made, I haven't seen reports of people using it on a daily basis (I mean the combination of vhd/vhdx with wim) while each of them separately seem to work fine. Personally (but I am notoriously, besides, picky, cheap and grumpy very "old school") I see a generic issue with compressed files when it comes (if needed) to recover a failed system (but nothing of course that cannot be solved through a "sound" backup strategy ) jaclaz

Well, to be fair, there is as always a bit of hype . The MAC's seemingly have NOT BASH enabled by default (and it is rare to find MACs hosting an http server with CGI and/or PHP). The "corporate" Linux servers, on the other hand, tend to have other means/layers of protection, and at least judging from the effects of the test scanning a nice chap did: http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html they are pretty much "safe". Detectify has put a simple online test: https://shellshock.detectify.com/ What are really "at risk" are IMHO more the less/badly maintained (or "fake" Open Source) little Linux devices (where the vulnerability may be present BUT NOT most of them as seemingly busybox is not affected) : https://www.nccgroup.com/en/blog/2014/09/shellshock-bash-vulnerability/ but more than that "home made" servers put together by the "half technical" good guys (technical enough to put together such a system, but not enough to secure it effectively) and devices that use a "more sophisticated" environment than busybox. In any case, the vulnerability is a rather serious one in theory, but in practice the actual effects (if any) seem like being much more limited than what initially hypothesized as, besides the BASH vulnerability it seems like there must be a number of concurrent factors to make the exploit actually have some impact. https://community.rapid7.com/community/infosec/blog/2014/09/25/bash-ing-into-your-network-investigating-cve-2014-6271 jaclaz

And light bulbs. Same mentioned article (go to the original to get the other links): http://www.troyhunt.com/2014/09/everything-you-need-to-know-about.html This is specific to LFIX light bulbs AND it is about another vulnerability, but the point made remains (potentially) valid: http://www.smh.com.au/digital-life/consumer-security/security-vulnerability-found-in-lifx-smart-light-bulbs-exposes-home-wifi-passwords-20140709-zt12p.html jaclaz

Maybe it is still connected with the "circumventing" mentioned in Rule #1.a? http://www.msfn.org/board/index.php?app=forums&module=extras&section=boardrules jaclaz

Maybe it's 88 pages because people don't take the little time to look into what was posted and makes a new post asking where a given topic has been discussed? However : http://www.msfn.org/board/topic/170850-aero-glass-for-win81-125/?p=1085704 jaclaz