jaclaz

Well, if it's allright a FREEWARE (not "Open Source") one, we already have it: http://users.pandora.be/jbosman/applications.html http://users.pandora.be/jbosman/dcopy.zip Please note that due to HAL limitations in the NT structure, it is NOT possible to access tracks beyond 80 on floppy disks under NT/2K/XP/2003, so anything that uses more than that can only be read in DOS (possibly with fdread or other similar program will be needed) or in Linux. See also this for more info on floppy formats and programs: http://www.msfn.org/board/index.php?showtopic=81068 jaclaz

Yep, or use this FREEWARE OPEN SOURCE utility: http://www.ridgecrop.demon.co.uk/index.htm?fat32format.htm B) jaclaz

UPDATE! Maybe, just maybe, I have found the right tool, though it is DOS/WIN9x/ME only: RECOVER Fixed/Floppy Disk v2.2 http://www.bestdiskrecovery.com/index.html#rfd1612 Adding a menu entry to the Grub4dos menu will be needed, chainloading a IO.SYS on root of stick, and one will need to boot to this entry to "regenerate" the stick, but it could work. OS files can be extracted directly from XP files, see this: http://www.911cd.net/forums//index.php?sho...c=16745&hl= I am still looking into writing a batch script to use findpart getsect/putsect functions with gsar, the thing that concerns me is the time of execution, and, talking about direct accessing a harddisk/stick, I need to test it on a non-production PC, so it will take a few days..... jaclaz

LOL! This is the typical example of how one can introduce a bug in less than 20 lines! I would have never thought about "reserved" words that are subsets of filenames .... Yes, I just put the # as they are more visible than spaces. I too had a look at scaven, but it is a DOS app, and while with the appropriate driver it would be possible to get it access a USB stick, it won't work in Win32 . There MUST be somewhere an utility capable of doing that, all it takes is to find it.... ....usually when you search for something else you will find it. Look at what I found while searching for this utility, a very good "GHOST like" app, buried inside the innards of Sourceforge: http://sourceforge.net/projects/nfgdump/ jaclaz

Yes, I can confirm that, the files are strictly compliant to 8.3 rules. Yes, the procedure to create the list of "pairs" must take care of this, but it is not difficult to make a batch to process the output of a DIR : @ECHO OFF SETLOCAL ENABLEEXTENSIONS SETLOCAL ENABLEDELAYEDEXPANSION FOR /F %%A IN ('dir /B') DO CALL :ADJLEN %%A GOTO :EOF :ADJLEN SET /A counter=0 SET /A length=0 SET filename=%~n1 SET fileext=%~x1 :loop1 Set /A counter=%counter%+1 Set filelen=!filename:~0,%counter%! IF NOT %filelen%==%filename% SET length=%counter%&goto :Loop1 IF NOT %counter%==8 set filename=%filename%#&goto :Loop1 REM ECHO %counter% %filelen% REM pause ECHO %filename%%fileext:~1,4% %~nx1 GOTO :EOF (please note that there is a [TAB] between "ECHO %filename%%fileext:~1,4%" and "%~nx1") Sample output of the above: is3#####cmd is3.cmd is3a####cmd is3a.cmd change##cmd change.cmd change2#cmd change2.cmd cartellacmd cartella.cmd Erlev###cmd Erlev.cmd colours2txt colours2.txt testcopycmd testcopy.cmd Choice##exe Choice.exe dirvmc##cmd dirvmc.cmd AUTOEXECBAT AUTOEXEC.BAT CONFIG##SYS CONFIG.SYS padnamescmd padnames.cmd temp####txt temp.txt tstcopy2cmd tstcopy2.cmd padname2cmd padname2.cmd Once we have our list with all its ###, a simple binary search and replace would make it in the format required. jaclaz

Yes, I came exactly at the same conclusion , I am having a look at it..... By the way, out of topic, but not much, another idea came to my mind, I'll just throw it in "as is" : what about a "superfloppy" image with the 6 XP floppy disks combined into one? I already tried - actually with the 4 Win2k floppies - and it does not work if the device is formatted as "hard disk" (with MBR - it asks for the $WIN_NT$.~BT folder), but I was at home on my wife laptop and missed some tools to work with image files and partitions, so I will try again as I find some time. The test I did, combining the first two floppies in a 2.88 image did work until it asked for the 3rd floppy, so, it may work with a bigger one, 5.76 for 2K and 8.64 for XP . It doesn't seem it has direct disk access, and if one has to copy sectors to file to process them, I would prefer gsar, which I know better. But maybe I missed something, what would they be the advantages of sed over gsar in this? jaclaz

Yep, that's what I was referring to originally, though I most probably suggested a WRONG method as a workaround, I simply forgot that files are not in ROOT, but rather in \I386, my bad. Most probably imaging more sectors will make the image too big for practical use. As said, deleted files 1st character is replaced by character "å", so, theoretically, all we need is a "database of deleted filenames/original filenames, something like: åDEFAULT.PI_ _DEFAULT.PI_ å2520437.CP_ 12520437.CP_ å2520850.CP_ 12520850.CP_ å394.IN_ 1394.IN_ ... and an application capable (with direct access to disk) to replace the pairs, something like gsar: http://gnuwin32.sourceforge.net/packages/gsar.htm ...but I seem not to be able to find any such program, though I am quite sure it must exist somewhere. Another possibility may, but I still have to experiment with it, the bunch of apps that you can find here: http://www.partitionsupport.com/index.html One could make a small ramdisk, copy to it a few sectors copied from the stick, apply the gsar substitution to them, and copy them back to stick, but I have the feeling that the processing time would be huge.... ....and off I go searching again for the right tool! jaclaz

You might have missed the start of this: http://www.msfn.org/board/index.php?showto...mp;#entry563654 The method using DOS 7.1 and WINNT.EXE has already been developed fully and has been published here: http://www.911cd.net/forums//index.php?showtopic=16713 One can later convert the FAT32 system drive to NTFS with the MS utility convert: http://www.microsoft.com/technet/prodtechn...convertfat.mspx convert C: /fs:ntfs though I never tried this myself and I have read conflicting reports about success of such an operation. @LLXX Yep, but still formatting a USB stick as FAT16 gives more probabilities to have it bootable on some motherboards. Using the DOS 7.1 files (or other FAT32 enabled DOS) is however needed, otherwise the resulting partition on the target drive will be affected by FAT16 size limit of 2 Gb. jaclaz

Good! Have a nice Thanksgiving... jaclaz

Happy it worked! Have a nice thanksgiving ! jaclaz

As a rule of thumb, even if you already burned that exact type of iso on that same hardware with success, always try with lowest possible burn speed, hit OK and go take a walk, sometimes burning at high speeds lead to errors or, even if burn is successful, to a CD that does not boot on anothe rreader/PC. 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