jaclaz

NO, but you should ALREADY have another alternative way to boot your system, like a floppy made along thiese instructions: http://www.xxcopy.com/xxcopy33.htm AND a backup of the data. jaclaz

Or you could make a (temporary) small RAMdisk to run these progs. Looky here: http://www.911cd.net/forums//index.php?sho...18845&st=58 jaclaz

I don't get it.... ...are you going to sue me for discrimination or for having missed it? B) jaclaz

Yes, of course it is possible, you might need to start reading something on it here: http://www.windowsnetworking.com/articles_...Windows_9598ME/ More specifically here: http://www.windowsnetworking.com/articles_...s/wxpwin9x.html jaclaz

@porear 1) no, the batch won't work in anything but 2K/XP 2) it will probably only work on FAT16 formatted volumes 3) and it assumes that the drive has only one primary partition starting at CHS 0/1/1, unless you supply on command line a different start address 4) as is, it is meant to be "interactive", no redirecting to a file will work on this version 5) there is no real "checks" for consistency made yet, so if the drive is not "properly formatted" it will probably fail Try using just findpart directly as this (provided that the stick is \.\\PHYSICALDRIVE2): findpart findfat 2 I am attaching the output of findpart findfat 3 (I am working on a virtual drive that is \.\\PHYSICALDRIVE3 and the corresponding output of savesect.cmd. Since my batch "filters" in a rather "dummy" way the output of findpart commands, it is VERY possible, if the output of findpart changes, that the batch fails. The other findpart command savesect issues is (on the drive 2): findpart chsdir 2 0 1 1 and I am attaching part of it's output on my drive 3 too. If you use directly findpart commands they can be redirected allright. jaclaz ssect3.txt fpartchs3.txt fpartff3.txt

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