jaclaz

I have not much ideas left: 1) Chkdsk sees the partiiton allright ÷190Gb 2) Windows Explorer ALSO sees it allright ÷190GB 3) Norton Partition Magic ALSO sees it allright ÷190GB 4) The error comes when you try to resize it That MUST be because somehow the disk (not the partition) is seen as having 16709 Cylinders, i.e. 132 Gb, and this happens with: a ) MBRFIX b ) TESTDISK c ) BEEBLEBROX d ) NORTON PARTITION MAGIC Results 1) to 3) are normal as to read information on the partition the MBR is read, which as said, is correct. Results 4) and a ) to d ) are also all coherent as to read information on the drive geometry the disk driver is interrogated, which actually interrogates the hard disk. So something must be wrong in EITHER: 1) the information the hard disk supplies, and this can be only be attributed to: 1a ) a jumper setting on the hard disk 1b ) a jumper or setting in the card or its BIOS 1c ) a setting in the motherboard BIOS that somehow "overrides" board one, though I doubt it OR: 2) the information the disk driver is correct, but it is badly "translated", and this can be only attributed to: 2a ) a defective driver (disk, card or bus) 2b ) a "hidden" setting or filter somewhere that "overrides" the right values From the "history" you supplied, the only other thing I can fathom is some kind of conflict with the SATA drive, so, yes, trying the drive hooked directly to the board would be a good troubleshooting step, though cannot say how many "good" info we can get from that. I would suggest the following: 1) just remove the SATA drive leaving everything else as is, run said apps to check if anything changed 2) remove DVDR leaving everything else as is, run said apps to check if anything changed 3) remove DVDRW leaving everything else as is, run said apps to check if anything changed 4) attach 186 Gb drive directly to MB leaving everything else as is, run said apps to check if anything changed 5) remove the card, run said apps to check if anything changed 6) re-insert card and attach to it 186 Gb drive, run said apps to check if anything changed 7) re-connect just the SATA drive, run said apps to check if anything changed 8) re-connect DVDRW leaving everything else as is, run said apps to check if anything changed 9) re-connect DVDR leaving everything else as is, run said apps to check if anything changed jaclaz

Hmmm, unless I am mistaken, your data appears to be correct, if you start from the partition, but maybe you missed the initial MBR and hidden sectors...: Counting whole DRIVE: 0x000000 (0 Dec) MBR 0x000200 (512 Dec) Hidden sectors (62 of them) 0x007E00 (32256 Dec) Bootsector 0x008600 (32768 Dec) 3 more reserved sectors 0x008000 (34304 Dec) FAT1 0x026A00 (158208 Dec) FAT2 0x044E00 (282112 Dec) Root Directory 0X048E00 (298496 Dec) First Data Sector Counting from Partition: 0x000000 (0 Dec) Bootsector 0x000200 (512 Dec) 3 more reserved sectors 0x000800 (2048 Dec) FAT1 0x01EC00 (125952 Dec) FAT2 0x03D000 (249856 Dec) Root Directory 0X041000 (266240 Dec) First Data Sector Now, let's see if the above is correct: MBR = 512 bytes Hidden sectors= 62x512= 31,744 bytes Bootsector=512 bytes More reserved sectors=1,536 bytes FAT1= 242 x 512 = 123,904 bytes FAT2= 242 x 512 = 123,904 bytes Root= 512 x 32 = 16,384 (each record is 32 bytes long) 512+31,744+512+1,536+123,904+123,904+16,384=298,496 and 512+1,536+123,904+123,904+16,384=266,240 If you use the dsfok with "partition" offset, you must give it a drive letter, whilst if you use the "Drive" offset, you can use PHYSICAL drive (and need to rewrite the initial 63 sectors). To automate the process while making sure you are rewriting on the right drive, the "fixed" letter for the USB stick through migrate.inf, that cdob proved to be working in the other thread might be useful . Also, have a look at the small batch I posted here: http://www.911cd.net/forums//index.php?sho...=15837&st=5 that should give you some ideas on how to make this. It has been some time since I "peeked and poked" on FAT filesystems with hexeditors, I cannot remember if there is something else that must be taken into account. I'll try and "freshen" my experience in the next few days, and post if I find something else..... ...as an afterthought, maybe there are some more appropriate utilities on the net, I'll have a look at them too. jaclaz

Well, I am afraid not, you see, the partition data in the MBR is correct, (the 390716802 you report, which is approximately the value I expected "Numsectors around 390,000,000"). To be more exact, a value of 390716802 in Numsectors would mean a CHS geometry of 24,321x255x63, i.e. 24,321x255x63x512=390,716,865x512=200,047,034,880 bytes, corresponding in "Hd Manufacturer Gb" to: 200,047,034,880/1000/1000/1000=200 Gb and in "real Gb" to: 200,047,034,880/1024/1024/1024=186 Gb So the MBR is correct, there must be something somewhere else, (at this point and from what you report I am inclined to think it could be something in the Registry, if you are positive that there is nothing "suspect" in the motherboard or card BIOS) that makes these utilities "see" the drive as 132 Gb. Can you try running a CHKDSK from a command prompt: http://www.ss64.com/nt/chkdsk.html WITHOUT any parameter and take note of what it says? jaclaz

Yep, it is possible, but as I see it, besides it actually meaning to rewrite the entire Operating System from scratch, you'll have to add rewriting all drivers, otherwise you won't have any real benefit from 64 bit computing...... jaclaz

erroneus enough: CHS 0/0/1 = 1st Sector on disk = Sector 1 = Sector 0 LBA is the MBR CHS 0/0/2 to 0/0/63 =Sectors from 2nd = sectors 2÷63 = Sectors 1÷62 LBA are hidden sectors (unused) CHS 0/1/1 = 1st sector in partition = Sector 64 = Sector 63 LBA is the partition bootsector Depending on size of the partition and number of directories entries, following sectors are FAT1/FAT2 and Root directory. Number of sectors used is written in bootsector, use either beeblebrox: http://students.cs.byu.edu/~codyb/ or Roadkil's Boot Builder: http://www.roadkil.net/bootbuild.html To explore the contents of your bootsector. Check the Starman's realm for reference: http://thestarman.dan123.com/asm/mbr/MSWIN41.htm http://thestarman.dan123.com/asm/mbr/NTFSBR.htm and here for FAT16: http://home.teleport.com/~brainy/fat16.htm http://averstak.tripod.com/fatdox/bootsec.htm http://www.ntfs.com/fat-partition-sector.htm or just use the two utilities and report contents of bytes 0x0E÷0x0F; 0x11÷0x12; 0x16÷0x17, respectively Reserved Sectors, Root Entries, Sectors per FAT. I am assuming that the volume has two FATs and is FAT16. jaclaz

hmm, it would be interesting if it were, it would change the commonly used (denigratory) definition of Win9x: However, the answer is no, as said Win9x is not even 32-bit, let alone 64. jaclaz

Yep, "unattended" matter should be taken in small doses.... jaclaz

Though personally I prefer drives multipartitioned, expecially with so large disks, wouldn't using a BartPE CD before install the easiest thing? jaclaz

Well, wait a minute before spending money, I would have thought that the trial would have given enough info. However it is not that expensive, and it's however a handy diagnostic tool. Let's try this before, manually: Check with Regedit that the keys are as in this articles: http://support.microsoft.com/kb/303013/en-us and check the version of ATAPI.SYS Double check your hard drives and their documentation if there is a jumper related to the 137 Gb barrier or something like "Limit number of reported cylinders". If the above is OK, the other thing that might be could be an incompatible BIOS of the motherboard and/or of the attached card, you should try looking on the respective manufacturer sites if any fix is available. Try also these two programs: SIW: http://www.gtopala.com/index.html and SIV: http://siv.mysite.wanadoo-members.co.uk/ both give lots of info on hardware and maybe you could find something from their output. You can also try to run from DOS the intel program: http://www.intel.com/support/chipsets/iaa/sb/cs-009302.htm http://www.intel.com/support/chipsets/iaa/sb/cs-009301.htm And this one (from XP): http://www.hdtune.com/ I'll post if any other idea comes to my mind.... jaclaz

That's a pity, I am convinced that by giving a RAMdisk in BIOS (ideas in my post above) it can be done.... I'll have to do some serious search on how to "hook" the hmload ramdisk with the XP ramdisk.sys driver.... jaclaz

Yep, I a a smart guy B), though the basic idea is not really new, from the Art of War by Sun Tzu, around (500 BC): ...and I probably just won the 2006 award for the most off-topic post of the year ... jaclaz

@Eyedoctor2 From what you report, it appears that you have somehow corrupted records, I have seen this hapen when a tool like Partition Magic or similar has been used and was interrupted, but it could be caused by almost anything. It is possible that the drive was originally formatted under another operatig system or using a third party tool with full LBA support. Let see things one by one. As I see it, the fact that drive 0 is the one attached to mainboard, even if without active partition on it, is normal, I think that Physical drives enumeration is dependant on hardware connections, so I would not be preoccupied by that, it should be quite normal that the BIOS detects drives attached to mainboard BEFORE those attached to expansion cards. From what you say, the data reported by Disk driver is CHS 16709x255x63, which would mean 16709x255x63x512=137,436,203,520 bytes In a perfect word, with a NTFS primary partition spanning over the entire disk, you should have, as seen in beeblebrox (don't be afraid to use it, it won't make changes to MBR unless you tell it to do so): You should have just one entry like these: Type 07 Boot 80 BCyl 0 BHd 1 BSec 1 ECyl 1023 #the "real" value should be 16,708, but CHS "stops" at 1023 EHd 254 ESec 63 Startsector 63 Numsectors 268,430,022 But, since your drive is "really" a 200 Gb, i.e around 186 Gb of "true" bytes: 200x1000x1000x1000=200,000,000,000 200,000,000,000/1024/1024/1024=186 It was most probably formatted with appropriate values for it's size, with Numsectors around 390,000,000. You can run beeblebrox and report them. I suspect, this is guesswork at the moment, that you hit a known limit or hard disk size barrier, the "48bit LBA one", see here: http://www.48bitlba.com/ you do not say which OS you are running, so, with another guess on my part, I would say Windows XP pre SP1: http://www.48bitlba.com/winxp.htm or Win2k pre SP3: http://www.48bitlba.com/win2k.htm DO run the tools you can find on the site: http://www.48bitlba.com/hdinfo.htm http://www.48bitlba.com/enablebiglbatool.htm and upgrade OS if necessary. Please do report your findings and (hopefully) the fix that worked. jaclaz

@JohnS You are right, TWO times. For the recovery of the "occasional" file, Read only NTFSDOS is better due to longname support, though it is not a recommended solution if you need to copy a substantial amount of data. To "access" a NTFS volume, NTFS4DOS is better because being Read/Write allows you for the, again, "occasional" fix/correction. Both solutions are not fast or handy for fixing/copying huge amounts of data, in that case a PE build or putting the drive on another PC as slave is preferred. About the Datapol link broken, it appears that Datapol has somehow been acquired or incorporated into AVIRA, relevant pages appear to be these ones: http://www.avira.com/en/products/recovery.html http://www.avira.com/en/products/avira_ntfs4dos.html http://www.avira.com/en/products/avira_ntfs4dos_4.html Although on last linked to page, the esistence of a personal version, free for private use is stated, the download appears nowhere to be found, maybe it is just a temporary problem.... However, it is available from another Avira website, here: http://www.free-av.com/antivirus/allinonen.html http://www.free-av.com/down/windows/ntfs_h.exe Another link here: http://wiki.fdos.org/DOS/Ntfs4dos http://mywebpage.netscape.com/rjbovitz/ntfs4dos.EXE jaclaz

There are some ongoing threads on the topic. With reference to my post here: http://www.msfn.org/board/index.php?showtopic=81788&st=6 Method 1) and 2) are OK, though method 2) might require a more verbose howto, method 5) is in the same thread almost complete, thanks to cdob, method 4) is almost working, thanks to porear here: http://www.msfn.org/board/index.php?showtopic=61384 Any taker to test method 3) ? jaclaz

Now I see, , just like the setup or whatever is running was using the MOVE command instead of the COPY one. I guess this is hardcoded.... , maybe in Setupdd.sys Another idea, why not letting the setup delete those files and later undelete them? Since no new data is written to the stick, files should be fully recoverable, it would just be a matter of going through the FAT/directory entries and rename the files with a leading "å" to their original name, or easier still, make a "snapshot" of the few sectors involved BEFORE running the install, saved to a file, and later restore those sectors from within the installed XP, with a suitable "Direct disk access" app, like the DSFOK toolkit: http://members.ozemail.com.au/~nulifetv/freezip/freeware/ http://members.ozemail.com.au/~nulifetv/fr...eware/dsfok.zip The overhead of having dsfi.exe and an image of, say, first 200 sectors of the stick would be negligible, around 15 kbytes as well as the time involved in the restoring.... jaclaz

If you can write a simple Vbasic program, it is possible, but I suspect that the way I normally do it is easier. I have an Excel spreadsheet where a database is kept with all "Fields" connected to a Word "template" I update the database fields, which can have formulas in them, copying one or more rows and adding them, that I use the "Mail merge" function of Word. Some reference to get you started: http://www.webopedia.com/TERM/M/mail_merge.html http://www.its.ipfw.edu/training/howto/mailmerge.shtml A google search for "mail merge" will give you more results. Once you have done it "manually" it is quite wasy to make a VBasic macro or function to automate it, but that's all another thing. jaclaz

Yep, just to keep things together and prevent possible misunderstandings, here is the thread where it all started: http://www.msfn.org/board/index.php?showtopic=61384&hl= jaclaz

@haggisnneeps Look here: http://www.msfn.org/board/index.php?showtopic=68252 http://www.911cd.net/forums//index.php?sho...c=13516&hl= http://www.911cd.net/forums//index.php?sho...c=16702&hl= jaclaz

Because, as said just two posts above, there is a FREEWARE Read/Write capable driver, more efficient than the reader. jaclaz

yep, but it is NOT an operating system and it does NOT boot from USB: http://www.msfn.org/board/index.php?showtopic=85569 jaclaz P.S.: @esallou, to save some time, should it not be working, here is a post of mine where I try to "sum up" the various tutorials with links to them: http://www.911cd.net/forums//index.php?sho...181&st=1988

Maybe you took too many things off with nlite, or maybe you missed some steps. I can guarantee that it is possible to install and boot a reduced XP image from USB, but it can be a long and troublesome experience. The original thread is here: http://www.911cd.net/forums//index.php?sho...c=14181&hl= The one you linked to is one of the derivatives. jaclaz

NTFS4DOS, here: http://www.datapol.de/dpe/freeware/ Works very well, in my opinion much better than the Wininternals/Sysinternals NTFSDOS, and, besides being Read/Write instead of Read Only - comparing freewares, it also takes much less space.... jaclaz

Well, as I read it, it seems to me that it was related to GRLDR installed on a NTFS partition, there should be no problems on a FAT one. The "boot" directive at the end of the menu entries should not be needed. I had a deeper look at the mstechnet article here: http://technet2.microsoft.com/WindowsServe...f63a971033.mspx It appears that the deletion takes place at step 7. below: or at step 10 below: At that moment it seems like TXTSETUP.SIF is not used anymore, other files like (maybe): Maybe something can be made in Unattended settings, though I doubt it. I am not at all an expert in setup, maybe there is a way, just before files are deleted, to execute a command to rename the folder to something else, and then set at next boot of the GUI (first real boot of the installed system) with RunonceEx or some other Registry entry, a command to rename folder back.... jaclaz

That's VERY strange. Try directy chainloading a setupldr.bin, something like: jaclaz

cdob, how big is the image, and how much RAM do you expect to be needed for this? Well, actually, no, but in latest releases there is a hmload.com tool that works that way.With "normal" DOS (or Linux for that matter), you boot to DOS, execute the hmload.com with the appropriate parameters this is an example: and it does a raw-copy of the given image file in RAM, i.e to the (rd) Grub4DOS device, then you invoke grub.exe from DOS, using parameters like: or (I am not 100% sure about latest syntax, I haven't right now handy the Grub4dos setup I had working) But I cannot say if it would work with a NT based syste, unless, you are right: Dietmar doesn't give us some more details about his ramdisk method described here: http://www.911cd.net/forums//index.php?sho...c=18326&hl= or some one finds another way, or try using one of the other programs.... ...also, in the same thread there is a reference to direct SDI booting from Grub4DOS, if you have time, can you try it and report? jaclaz