EDITED

I formatted the stick and got everything booting using the SETUPLDR.BIN renamed as NTLDR. I then replaced the NTLDR with the GRLDR renamed as NTLDR - and get only a flashing cursor in the top left corner of the screen.

I tried the boot.ini method and it works, but so far both of my original menu.lst entries end up booting right back into the stick and GRUB. ?? I'll have to work on this. Even working at the command line, I reboot into the stick.

rootnoverify (hd0)
chainloader +1
boot

and

rootnoverify (hd1)
chainlaoder +1
boot

do exactly the same thing.

In other news, wasted some time before I realized my USB stick was fried - formatting kept hanging up. I tried wiping the disk, including the boot sector, and starting fresh, but in the end it was a hardware issue. Had to get another stick.

Sorry for your stick.

Maybe, depending on make/model, or to be more exact actual USB controller that it is on stick, it may be possible to use the manufacturer Production Tool to "low level" format it to factory condition.

Please post Vid&Pid of the device, maybe it's one of those for which a tool is available.

About the GRLDR renamed as NTLDR, it is possible that it is one of those cases that it doesn't work, but through "real" NTLDR/BOOT.INI it SHOULD work.

Try using the Find command in Grub4DOS with autocomletion, i.e. type:

(the above means type "find", an open parenthesis (, then press the TAB key.
It should list devices available....

Is it possible that it is one of those incompatibilities with motherboard BIOS (i.e that it reads CHS ok, but not LBA or viceversa) ?

jaclaz

P.S.: cdob just reported that the "other" method is working:
http://www.msfn.org/board/index.php?showtopic=81788&hl=

No worries about the stick, I've already trashed it. It was fun prying it apart and playing with the insides

Thanks for this, I was looking for a way to do that:



I have fd0, hd0, hd1, rd

Now that I no longer have GRUB in the MBR, for some reason everything points back to teh first sector of the USB stick, which goes through NTLDR to GRUB.

That's VERY strange.

Try directy chainloading a setupldr.bin, something like:


jaclaz

That worked. The new menu.lst is


With regards to the renamed GRLDR, this note in the GRUB4DOS readme.txt might apply?:


I am still working the other file deletion issue, I've printed out TXTSETUP.SIF and the deleted files list. So far in doing a visual comparison, nothing jumps out.

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

Those are all good ideas, thanks so much for putting so much effort into researching this. Its definitely out of my experience level.

I've posted this particular question back at the top (Windows XP) level of the forum so maybe the added visibility will atttract the attention of a setup expert.


In our case for these specific files, it is happening before this stage. That entry is in the final GUI mode stage, whereas our files are deleted as they are copied while still in text mode in the very early stages. Its actually here, which is step 10 of the Initial Stage:


However, you are right, once we get there that we will be looking for a way to stop deletion of the entire $WIN_NT$.~BT and $WIN_NT$.~LS temporary directories during final install cleanup. I believe this is the step 10 you mention.

I wanted to submit a quick clarification that may cover some misunderstandings about the problem that is occurring.

When text mode setup is ran from the stick, all the usual steps are encountered (pick a partition, format the partition or leave alone, check for appropriate disk space, etc).

Then file copying begins. The files we are trying to save are each deleted one by one as they are copied, not as a batch at the end. If I let a few files get copied and interrupt the install, those files are already gone from the stick.

This is a separate and more immediate issue than the deletion of the temp install directroies at the end of GUI setup.

Hope this helps some... thanks!

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

You are correct, its acting just like a move.
I thought this might be the case and I had tried poking around in setupdd.sys with a hex editor but found nothing I could recognize to alter.


I think that is an EXCELLENT idea. I had the blinders on and thought the only way to recover would be to recopy all the files again, I didn't consider it might only need an undelete.

A candidate for initiating this might be the cmd switch when winnt32.exe is ran, apparently it somehow codes custom commands to be run later. I'll have to experiment unless someone is familiar with this switch, because the two references I have found about it do not seem to me to agree about when it happens:

from http://winsupersite.com/showcase/win2k_cmdline_setup.asp
and from http://www.quepublishing.com/articles/arti...qNum=6&rl=1

Yep, I a a smart guy , 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

hehe very nicely done. This thread was about due for a dose of OT

Playing with dsfo now and trying to determine the length of the FAT, am thinking I read somewhere the boot record including FAT is 63 sectors, so 63 * 512 = 32256. Just how erroneous is that?

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

That should be correct. Thanks for the info and references, I'll look at them. This project is opening up quite a few new things to me.

Beeblebrox reports C/H/S for the USB is 246/255/63.
NumSectors in the partition table is 3963841.



Using WinHex (and Beeblebrox to double check) to observe the bytes mentioned,

0x0E÷0x0F Reserved Sectors data is 04 00
0x11÷0x12 Root Entries data is 00 02
0x16÷0x17 Sectors per FAT data is F2 00

Choosing to jump to FAT1 in Winhex points to offset 0x800, and FAT2 is at offset 0x1EC00. From the data, this should be my drive:

Offset 0x0 is Boot sector
Offset 0x800 is FAT1
Offset 0x1EC00 is FAT2
Offset 0x3D000 is Root
Offset 0x41000 is First data sector

0x1EC00 - 0x800 = 123,904. This length agrees with the calculation 242 sectors/FAT * 512 bytes/sector = 123,904 bytes/FAT.

As always, thanks so much for the continued assistance.

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

UPDATED See flagged note below

I think my method of experimenting is flawed. I am using the disk offset of 282,112 (also tried 298,496) and addressing the USB with the scheme \\.\PHYSICALDRIVE1

I am doing all of this from within Windows XP (which I think is a problem)

Save through FAT2 with dsfo \\.\PHYSICALDRIVE1 0 282112 fatsav1.dsk
Delete several files from the stick
Restore back to the stick with dsf1 \\.\PHYSICALDRIVE1 0 282112 fatsav1.dsk
Save another file through FAT2 with dsfo \\.\PHYSICALDRIVE1 0 282112 fatsav2.dsk
Compare the two saved files fatsav1.dsk and fatsav2.dsk with WinHex

The files are identical, so the restore succeeds. However, the deleted files do not reappear in Windows Explorer.

If then I do a View->Refresh of the USB drive in Windows Explorer, then save another snapshot with
dsfo \\.\PHYSICALDRIVE1 0 282112 fatsav3.dsk

Differences are found between this and the first two snapshots! I've attached REPORT.TXT generated by WinHex that shows the differences.

It seems as if Windows XP has the first few sectors of the USB disk cached, and assumes that direct disk writes that bypass XP will not take place. The refresh action seems to write the XP cached data back to the disk. Is this a feasible theory?

Update: I have tested this theory by removing the USB stick after restoring the FAT, then plugging it back in. Sure enough, this does seem to destroy any XP cached FATs, and the deleted files and folders reappear. HOWEVER... Only files and folders in the root are undeleted. Folders that originally held files that are undeleted to the root are now all empty. So, the root directory is being restored, but not the FATs

If this is true, will the same problem arise in the setup/install environment? I have not tried it yet since my experiments have failed so far.

I also am searching for other possible existing utilities for backup/restore of the FAT, or an undelete that will work in the install environment.

I'll write back when I have anything new, but may not be on as much for the next few days, its holiday time here. I will also look at the link to the batch file you posted. Thanks!! BTW, I've been making it a point to honor the provisions of your CareWare license today, my friend.

Good!

Have a nice Thanksgiving...

jaclaz

Could you not copy a dos floppy to the flash drive, then edit autoexec.bat? to run winnt.exe (Setup App intended for dos prompt). I managed to do this for win 98se, but i know a few of the dos files need tweaking a bit. Your flash drive should be formated as fat, not fat32 or ntfs as dos does not support these.

DOS 7.1+ kernel (in Win95b and above) supports FAT32.

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

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

uuuuuuuughhhhhh too much food. Hello, Puggsley and LLXX.

I've been trying to determine what happens during a file deletion. Not only is the FAT altered, but one byte per file (I am assuming the first) is overwritten as well. It appears that this is the first character of the file name that must be manually supplied for most undelete methods.

Experiment: I imaged through the end of my FAT tables (img1), then imaged the whole stick (img2). I deleted 3 files, restored the FAT from its image (img1), then re-imaged the entire stick again (img3). Comparing the two whole-disk images (img2 and img3) resulted in 3 differences found, in attached REPORT.TXT.

The 42, 47, and 47 that were overwritten should correspond respectively to b, g, and g in the filenames bootlace.com, grldr.mbr, and grub.exe.

So, for successful automatic undelete, the first character of all file names must be saved prior to deletion and then restored. I am assuming this is what "delete tracking" in the old DOS undelete did.

http://free-backup.info/file-recovery-usin...s-undelete.html

This would be perfect, unfortunately it requires a DOS 5.22 to DOS 6.0 environment to run. I've been looking but have not come across a similar tool that works in our XP Setup environment.

From http://www.computerhope.com/undelete.htm


I hope we're not digressing too much here to chase this as a solution to the file move issue, especially since this was already "Plan B" Although my talents are limited in this area, I might look at what it would take to try to write something that approximates the undelete "tracker".

I ahd thought that although it complicates things, maybe we could alternatively boot to DOS, XP Setup, then DOS again and use the existing undelete with tracking. However, the tracking has to be running when a file is deleted for it to be added to teh tracking file.

So could this method not be used? After all the boot.bin is located in the nlite folder (if you have nlite installed!)

use mkbt to set the usb key up and copy the contents of the cd over?

I may try this just to see what happens

Edit: never mind. My USB key is not interested in working with this.

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:


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

hehe and I as well. As a tip, I have found that the term "file system snapshot" is turning up some interesting results, but have not gotten in too deep yet.


This might not actually be that hard to do. I know the 3,025 files in question that are deleted and could make the database easily. This database would contain only the filenames and not their locations, so a complete search would have to happen for each file.

My only concern would be that if gsar searches the entire disk each time to make each replacement, this may be impractical for the time required. A more targeted approach that would use the FAT information to go straight to the file would use a fraction of this time.

Possible idea:

Tiny Hexer at
http://www.mirkes.de/en/home.php

It's free, it's scriptable. Maybe there is a (scriptable) way to feed it the text file listing of file names, search for the location of each of the file names on the disk, and record these locations in the text file with the names.

Then... create a batch or script file to use dsfi to restore the first character of each file name after deletion based on the text file created above.

What do you think?

Try sed, the stream editor.

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

That sounds way too easy - now where is the fun in that? Just kidding. The problem I have had with that type of approach has always been that once the text mode setup has finished loading (the part that is on the floppies) that I cannot get the installation to continue since it asks for the CD. This occurs even if I have the CD tag files on whatever medium I am trying to install from. I am sure this could be solved, I just have not yet been able to do it.

Regarding the Tiny Hexer approach, I think it is possible, but it will require another step: the file names on the disk are in 8.3 format, so to search for them, our match list will first have to be modified.

Looking at the installation files, I do not believe any have names longer than 8 characters, but some have less. On disk, these shorter names are padded with spaces (0x20) at the end, e.g. boot.ini becomes

BOOT INI (four spaces between boot and ini)

Unfortunately some of the shorter deleted files have the same name with different extensions, so we cannot just search for åclui, we must search for

åCLUI CH_ (three spaces in between for all of these)
åCLUI DL_
åCLUI HL_

Simple enough, just another step.

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 :


(please note that there is a [TAB] between "ECHO %filename%%fileext:~1,4%" and "%~nx1")

Sample output of the above:



Once we have our list with all its ###, a simple binary search and replace would make it in the format required.

jaclaz

Maybe not for you! hehe Very well done, sir. Works perfectly. I made a couple of very minor tweaks.


I believe the #s actually need to be spaces (0x20).

This next one threw me for a while. It was very strange, but the batch file made it through most of the directory then crashed. Turns out it didn't like the file "notepad.ch_" because when it parsed the name, it was literally translating the first three letters "not" as a NOT. I used some quotes and its works great.



I have been looking at Tiny Hexer scripting capabilities, and unless I am mistaken, "search" does not seem to be a scriptable function It is available in WinHex scripting capabilities, but not in the free version.

We really just need a way now to obtain the hex offset of all of the file name locations. It still seems like with that additional piece of data this would be a suitable task for a batch that employs dsfi. We would not even need to rewrite the entire file name, only go to the offset where each name is located and rewrite the first 'å' byte.

I found a tool that sounded suited for this at

http://pjwalczak.com/scaven/index.php

but alas it wouldn't see my USB disk, and the input file is limited to 512 bytes (our list is 26K). I've written the author but wouldn't consider this a very probable solution.

This tool, NT_SS is even more perfect, but carries a $50 tag. Its functionality is exactly what I am seeking.

http://www.dmares.com/maresware/html/nt_ss.htm

I am attaching replace.txt. It has the deleted name on disk, the first character that was replaced for each name, the original name on disk, and the original file names.

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

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

I had seen (and even downloaded) RFD but passed it over. Maybe I need to look at it more carefully. It looks like it isn't free. EDIT The 1.4 version is free.

You are right, we could regenerate from the XP installation back to the disk. Another option might be to simply have a second copy of all the deleted files on the disk and copy them back over each time, but I was hoping to avoid fragmentation. The deleted files total about 144 MB, which still take some time to copy on a USB, but it isn't unbearable.

So far the closest I have found to what I have been looking for is NT_SS mentioned previously

My best hits have come when searching for "physical disk search" and "hard disk forensics"

This search for disk offsets only has to occur once, so (as you also have ascertained) we still have flexibility for the environment the search runs in. Even a GUI app that spits out a text report would do the trick...

UPDATE: I took your suggestion of chainloading IO.SYS on the stick in GRUB. I was able to run Scaven! Not sure yet how fast it is. The main limitation with this approach is that the input file of search strings can only be 512 bytes - and our list is 40K. It could be split into 70 separate files and run by batch, but this seems a bit impractical.

thx to jaclaz for pointing me here...
I too am trying to setup XP from USB (without PE or DOS assistance).

Searching just now I found THIS.

It's called 'Flashboot' and is buried in side the nlite addon. I can't say more but will test it out later and see what's up. It has an option to convert a bootable iso image to a bootable USB device.
Perhaps this combined with 'SetupSourceDevice' altered in txtsetup.sif will work, who knows. I do have a feeling the answer to this one is more obvious than one might think. I would like to think grub isn't required for this task.
--
upd
--
flashboot is shareware and only makes boot disks out of isolinux and floppy based images, oh well, the search is on again.

Hi guys, first of all you did great job so far , following your posts I beleive you are on the right way and it is doable and I think we are one step closer.

Changing this line( actually only removing the 1 at the end of the row) it managed to keep most of the files during TXT portion of the setup. I tracked the changes comparing the folder contents of \$WIN_NT$.~LS\i386 before and after TXT setup using BeyondCompare 2 and found that most of the files were deleted if in [SourceDisksFiles] the file was listed as logonui.exe = 100,,,,,,,2,0,0 . I couldn't find clear explanation of all switches and decided to experiment. Removed the 1 and more than 200MB in files were not deleted, compared to the option with the 1 present.



Original txtsetup.sif:


New txtsetup.sif:



Now much fewer files are being deleted, some of them :



I will try to remove the second 0 for some files and will report the results.

A full list of the deleted files is attached, as well as txtsetup.sif.

I hope there is someone who could explain or give another clue what else needs to be changed in txtsetup.sif.
Meanwhile I will make a full list of all files deleted, with their options in txtsetup.sif.

Once we make it not to delete files during TXT mode we need to find a way to prevent the 2 folders $WIN_NT$.~XX not to be deleted from the USB stick at the end of the GUI mode, it completely deletes the 2 folders at the stage "removing any temorary files used..." and if one removes the stick after, say "registering components" stage, SETUP won't complain about missing files or media, tested it already. May be a script renaming the 2 folders? But how to launch this script right after "creating start menu...." or "registering components..." stages?

Some information about setup parameters can be found on this site, I will be digging in it next days:
http://www.osronline.com/ddkx/install/inf-format_0icy.htm

@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

Well, no luck so far, actually I was wrong thinking that the magic "1" changes anything, the mistake was that as a lazy man a few times I used hibernate during the tests and windows probably reported the deleted files as present.
I tried different options in txtsetip.sif and winnt.sif, tried to change source paths and so on, but no luck. I rather think deletion is hard coded and because $WIN_NT$.~LS folder is considered as temp folder files in it would be deleted on a few stages.
I also tried to leave $WIN_NT$.~BT required during TXT setup and replace $WIN_NT$.~LS with the original I386, also tried to point setup to look for I386 changing options in the 2 sif files, but it only goes to the format stage, tries to format and says something like "setup cannot continue, low memory or corrupted files on the CD". Playing with SetupSourcePath = "\" in [SetupData] section in txtsetup.sif didn't help, or I didn't find the right one.

I am giving up for now using this method, I'd rather spend time on booting from SDI image or a quick way to recover the deleted files. At the end of the day having pico, nano etc. PE gives much greater flexibility.

Next days I will have a look at the above mentioned tools and script. Thanks for your participation again.

Hello, ilko_t. Welcome and thanks for the efforts.

Sorry I've had a short lapse on this, life's been busy - we're expecting a baby!

Thanks for the code jaclaz. My batch script skills are lacking what is required for this task. I had been considering throwing together some pseudo-code for what was needed, but looks like you have it covered. The basic idea is to traverse the FAT and record the on-disk address pointed to of the first byte of each file entry (the first character of each file name).

I tried the batch, but was unable to get it to work for me. I know I am most probably not using it properly I do have FindPart in the same directory as savesect.cmd.

I ran the batch from a command line in Windows. I tried both Physical disk 1 (my hard disk) and Physical disk 2 (USB stick), with output redirected to 1.txt and 2.txt respectively. These files are attached, as are the screen outputs for each run in screen1.txt and screen2.txt.

I tried also booting to DOS on the stick and running the batch there. I'm using DOS 7.1 from Win98, and COMMAND.COM does not recognize .cmd files. I changed it to a .bat, but it still won't run. It skips accepting input when asking for "YES" to confirm reading the boot disk, and immediately displays "LABEL NOT FOUND". I am assuming this is from a GOTO LABEL in the batch script.

I've played with imaging the USB drive, then using gsar to search the image for the file names to provide the offset addresses. It works, but it finds 3 occurrences of each so we'd have to determine which is the one we want. It takes about 30 secs per file, which is actually pretty fast, but will take over a day for all 3000 files. This only has to be done once, but it's still extremely inefficient. A batch to process a list of all the file names would be needed too.

Since the files are on disk in alphabetical order, the search could be shortened by starting subsequent searches at the sector where the last match occurred. Unfortuantely, gsar does not accept a file offset from which to begin a search. I am sure other utilities could be found that would.

@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):


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

Progress. uuuuuuuggggggh I was using the wrong version of findpart - I had the DOS version.

I've been able to run the batch, the first part for finding the FATs and ROOT seems to work fine. The directory entries part of the code did not work for me, I have not began to troubleshoot yet. My output is attached. Thanks!

Yep, there might be some problem in the directories parsing, can you post the output of


I just tried with "simple" directories with short names and no spaces in name, most probably the latter is the problem....

jaclaz

Wow that's fast, worked great. Output attached in two parts, the file was over the posting limit.

Also, just out of curiousity, I used dsfo to make an image of the first 700MB of the stick to my hard drive. Restoring the image takes only a few minutes (less than 5) but this method requires an additional 700M of storage. I am sure it would have taken considerably longer had the backup image also been on the stick, and of course twice as much space on the stick would be used. Not the preferable way to go.

I'll have a look at fixing the batch to "catch" the right directories.

Yes, DSFO, not having an option for starting from an offset, is not the right tool....

I was thinking about using dd for windows:
http://uranus.it.swin.edu.au/~jn/linux/rawwrite/dd.htm
which does have a "skip=" option

Or a combination of:
1) findpart putsect
2) piececopy:
http://www.inner-smile.com/dl_piece.htm
(don't be fooled by the screenshot, it can work even from command line....)
3) a batch to run the programs


The thing that still leaves me wondering, I'll have to do some tests about it, is where the files beyond the first (512bytes/sector/32bytes/sector=16 entries - 2 (. and ..) =14) are listed.....

jaclaz

What version of dsfok do you have? I thought it was possible to start from an offset - I am using #4b. From the readme


I've been researching to learn more about the FAT and directory structure on disk. Here are some good references. You may have found the same or very similar.

http://home.teleport.com/~brainy/fat16.htm
http://www.mcmillan.cx/fat.html

From what I gather, there is no central master table for entries other than the root. The rest are spread out over the disk. The FAT has a single entry for every cluster in the data section on the disk. The entry in the FAT for each cluster indicates whether the cluster has data, is unused, or is the last cluster for a file.

Directories are just a special file on disk with the table structure discussed in the second link above. An entry in the table points to the first block of data in the directory.

From the references, as I (think I) understand, FAT entries in these ranges mean the following

0000h available cluster
0002h-FFEFh next cluster (or first?) in file
FFF0h-FFF6h reserved cluster
FFF7h bad cluster
FFF8h-FFFF last cluster in file

If this is correct, we would need to parse the FAT, and look for all entries in the 0002h-FFEFh range that follow an entry that is NOT in the 0002h-FFEFh range. These entries will point to the first cluster of each file. The first byte in these clusters should be the first letter of each file name that will need to be backed up and restored. (This needs to be verified)

I also believe that for the situation to be this simple, we are assuming that files have no fragmentation and are completely contiguous. If not, we would have to follow the trail of the "next cluster" entries and where they point for the next piece of a file until we encounter a "last cluster" entry.

I hope that helps and perhaps provided something you didn't already know. I also hope it is all correct!

Idea: Maybe comparing before/after FATs will help identify pointers to the files that have been deleted, so that we only back up those that are necessary instead of all.

Update: Here is the FAT spec from Microsoft. Have not looked at it in depth yet but looks like it should answer all our questions. The pages are titled FAT32 but cover FAT12 and FAT16 as well.

http://www.microsoft.com/whdc/system/platf...are/fatgen.mspx

porear
thanks for the links I'll study them.



Well, no, from the same readme.txt:


If you have time/will to experiment with different "low-level" data copying program, here is a pretty much complete list:
http://www.911cd.net/forums//index.php?showtopic=16534

The findpart putsect command should be more "accurate" as it works one sector at the time, also Roger Layton stated that he would implement in his MBRwiz a similar function, but even now, with 2.0 beta:
http://mbr.bigr.net/
http://www.geocities.com/mbrwizard/MBRWiz2.0.zip
http://www.geocities.com/mbrwizard/reference.html
one can use the /Sector - /Copy= and /Save= - /Restore= to achieve the same result.

jaclaz

Sorry I've been unavailable for a few days. Thanks for the links jaclaz, I will give the tools a shot. I'll try to make sure they have the basic functionality needed, as well as try to test their relative performance (speed).

Just a quick update, just to say that this has not been abandoned, though I had very few time to look further into the problem.

I'm a bit stuck at the moment.

On my test virtual drive, with a cluster of 8.192 bytes formatted as FAT12 under 2K, it appears that I can create (beginning from a 00ed drive, just formatted):
exactly 127 entries in a directory in root, 128th entry goes out of the cluster.

This makes sense, as directories "." and ".." entries take 32 bytes each, while the 127 files (LFN) take 64 bytes each, thus:
2*32+127*64=8.192

Problem is understanding where the 128th entry is made and where this address is referenced....
...it seems like the entry is simply appended at the end of the 127th file.

It seems like findpart finddir is not the right tool to find this address...

...however, I'll take my time over Christmas Holidays to see if I have an idea....

Stay well, see you on the beginning of january, Merry Christmas and Happy New Year.

jaclaz

I have been out of town and this "hobby" has been overtaken by enjoying time with family However, certainly not abandoned, will be back in January as well.

Your findings are consistent with the Microsoft FAT spec
http://www.microsoft.com/whdc/system/platf...are/fatgen.mspx
FAT12 and FAT16 have a fixed root directory size, while FAT32 does not.



I had assumed that this root directory limit would be enforced by the OS, and you would not be allowed to place more than the maximum entries in the root on FAT12 and FAT16. Maybe that is not the case. The answer is probably in the spec, which I'll look over more when I can.

In the mean time, have a wonderful Christmas and Happy New Year!!

Hello,
Windows will not just install as it is off a USB Drive, as many people has said, it needs a CMD Windows of some sort to launch a simple batch file that will copy over all the files Format your HDD, then install with your winnt.sif or unattened.txt file. So you need to find something that will boot off it, or make your own Custom Boot image, that will launch the CMD window, (Such as a Windows 9x* Floppy Setup Disc). then run a batch script automatically from with in that CMD window, so setup can launch the winnt.exe file, i Know i have repeated wot i have said here, but i hope it makes sence, and that it helps you

Ethan.

Ethan,
you see, the method you described does work, here we are simply trying to see if ANOTHER method is possible.

See the original post:
http://www.msfn.org/board/index.php?showto...mp;#entry563654
where I gave numbers to possible options.

The one you suggested looks to me like method #1 or #2 (method #1 is fully documented in 10 steps in the given link - at the moment unavailable due to some problems on the 911CD board).
GOOGLE cache here:
http://209.85.129.104/search?q=cache:FUaFj...owtopic%3D16713

Writing a batch to automatize it should be trivial.

With all due respect, I don't think that simply stating taht another way won't work helps, if you can hint anything on WHY it wouldn't work, it would be much appreciated.

jaclaz