jaclaz

I think it mainly depends on the TYPE of ZIP drive you have, there are mainly three types of "IDE" ZIP drives, see here: http://www.win.tue.nl/~aeb/linux/zip/zip-1.html If the drive is set as "superfloppy" most likely it won't be detected. You should however find an unidentified device with either a question or an exclamation mark in Device Manager. jaclaz

I am not really sure to have understood what you need..... to convert FAT volumes to NTFS there is Convert.exe: http://www.microsoft.com/technet/prodtechn...convertfat.mspx http://support.microsoft.com/kb/214579/en-us http://support.microsoft.com/kb/314097/EN-US/ (of course under 2K/XP) jaclaz

The procedure CptMurphy suggested may only work if it's an XP Home system, if it's Pro you need a different approach. The easiest methods are: 1) Use the UBCD: http://www.ultimatebootcd.com/ that includes the NT Password editor: http://home.eunet.no/~pnordahl/ntpasswd/bootdisk.html 2) Use this online service: http://www.loginrecovery.com/ There is also this "poorman's method: http://pubs.logicalexpressions.com/pub0009...icle.asp?ID=305 if you have the original XP CD, serial and no Service Pack applied, otherwise you will need a slipstreamed CD with the same or later SP. (untested on SP2) jaclaz

Yep, sure. What kind of damage do you think there is? TESTDISK: http://www.cgsecurity.org/wiki/TestDisk can easily rebuild a damaged partition table, but it includes PHOTOREC to recover deleted files too. jaclaz

ohh...my... , I had thought, as John Newbigin put it, that http://uranus.it.swin.edu.au/~jn/coke.htm jaclaz

Though this is increasingly going "out of topic", you might want to have a look at this thread here for freeware imaging solutions: http://www.911cd.net/forums//index.php?showtopic=16534 jaclaz

@LLXX On second thought, you can experiment with the ReactOS floppy disk driver, or try with the "installable" one that vizzini made: http://www.reactos.org/pipermail/ros-kerne...rch/002778.html jaclaz

@ilko_t Welcome to the game! Interesting results.....keep 'em coming. On the other side, I now have a still VERY preliinary (read as ALPHA, i.e. don't even think of using it on a large drive) batch file that uses FINDPART to get the address of the sectors one needs to backup. http://www.partitionsupport.com/utilities.htm It still needs to be refined, bettered, and possibly corrected, but it works OK, on small drives. I had to re-start from scratch a couple of times because I was using the wrong FINDPART commands, and I kinda got carried away (as often happens to me) and wrote something a bit more "wide" than what really needed, but there is always time to "reduce" it back. The search is limited at the moment for just a few directories. Please try it and let me know if it gives problems. jaclaz savesect.zip

The problem should be within the Floppy Disk Driver, which, if I am not mistaken, is flpydisk.sys. There is also the fdc.sys, maybe is this latter the culprit. Have a look at this: http://support.microsoft.com/kb/321697/en-us Basically you need to write a new (or patch the existing) driver. Maybe you can have some ideas "peeking" in the Source code for the XP 1.44 unconditional formatter: http://www.denispetrov.com/?page_id=3 though I cannot say if it uses "low-level" instructions or not. Another thing that might be an obstacle is WFP , cannot say if the driver is one of the protected files or not. 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