Jump to content

Welcome to MSFN Forum
Register now to gain access to all of our features. Once registered and logged in, you will be able to create topics, post replies to existing threads, give reputation to your fellow members, get your own private messenger, post status updates, manage your profile and so much more. This message will be removed once you have signed in.
Login to Account Create an Account



Photo

How to boot/install from USB key ?


  • This topic is locked This topic is locked
485 replies to this topic

#51
porear

porear

    Newbie

  • Member
  • 49 posts
  • Joined 10-August 04
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.

Edited by porear, 17 November 2006 - 10:19 AM.



How to remove advertisement from MSFN

#52
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,669 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag
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:

find ( [tab]

(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) ? :blink:

jaclaz

P.S.: cdob just reported that the "other" method is working:
http://www.msfn.org/...topic=81788&hl=

Edited by jaclaz, 17 November 2006 - 11:06 AM.


#53
porear

porear

    Newbie

  • Member
  • 49 posts
  • Joined 10-August 04
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:

find ( [tab]


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. :blink:

#54
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,669 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag
That's VERY strange.

Try directy chainloading a setupldr.bin, something like:

Title directly load SETUPLDR.BIN
find --set-root /setupldr.bin
chainloader /setupldr.bin


jaclaz

#55
porear

porear

    Newbie

  • Member
  • 49 posts
  • Joined 10-August 04
That worked. The new menu.lst is

color black/cyan yellow/cyan
timeout 10

default /default

title Phase 1 WinXP Text Mode Setup from USB
rootnoverify (hd0,0)
chainloader (hd0,0)/setupldr.bin
savedefault 1
boot

title Phase 2 WinXP GUI Mode Setup from Hard Drive
map (hd1) (hd0)
rootnoverify (hd0,0)
chainloader (hd0,0)/ntldr
savedefault 0
boot
With regards to the renamed GRLDR, this note in the GRUB4DOS readme.txt might apply?:

Someone reports that Windows XP with newer SPs and Windows Vista have intentionally broken the compatiblity with many things(including GRLDR). So you will get into trouble with these systems.

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.

Edited by porear, 17 November 2006 - 09:48 PM.


#56
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,669 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

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

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.micr...f63a971033.mspx

It appears that the deletion takes place at step 7. below:

Upgrade: Final Stage (Also Known as GUI-Mode Stage)

1. Using Plug and Play technology, Setup loads appropriate device drivers for the attached devices.

2. Setup configures settings using the existing registry as a baseline.

3. Setup copies files to the hard disk for operating system components that have not yet been installed.

4. Setup installs Start menu items and makes changes to the registry.

5. Setup sets file and folder permissions to protect the new operating system, for example, for files in the root directory, the system root folder, and the registry.

6. Setup runs Windows File Protection to ensure that all upgraded files are valid.

7. Setup removes any temporary files used during the installation process.

8. Setup restarts the computer. A few final user settings are applied after this restart, much like the process that happens at the beginning of any restart. The upgrade is then complete


or at step 10 below:

Clean Installation: Final Stage (Also Known as GUI-Mode Stage)

1. Using Plug and Play technology, Setup loads appropriate device drivers for the attached devices.

2. Setup requests information about the following items:
• Regional and language options
• Your name and the name of the organization (the name of the organization can be left blank)
• Product key
The 25-character product key is printed on a sticker on the back of your Windows Server 2003 product CD case.
• The licensing mode
• Computer name and administrator password
• Date and time settings

3. Setup installs a basic set of network components to begin the process of establishing network connectivity.

4. Setup requests information about the following items:
• Networking settings
• Workgroup or computer domain

5. Setup configures the settings that were specified.

6. Setup copies files to the hard disk for operating system components that have not yet been installed.

7. Setup installs Start menu items and makes changes to the registry.

8. Setup sets file and folder permissions to protect the new operating system, for example, for files in the root directory, the systemroot folder, and the registry.

9. Setup runs Windows File Protection to ensure that all installed files are valid.

10. Setup removes any temporary files used during the installation process.

11. Setup restarts the computer. A few final user settings are applied after this restart, much like the process that happens at the beginning of any restart. The installation is then complete.


At that moment it seems like TXTSETUP.SIF is not used anymore, other files like (maybe):

Sprestrt.exe and Undo_Guimode.txt

Sprestrt.exe, which runs at the start of GUI mode, determines if GUI mode ran previously and failed. If so, Undo_Guimode.txt is used to bring files back to the state appropriate for the beginning of GUI mode.


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.... :huh:

jaclaz

#57
porear

porear

    Newbie

  • Member
  • 49 posts
  • Joined 10-August 04
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.

It appears that the deletion takes place at step 7

or at step 10

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:

10. After carrying out the specified partition and file system changes, Setup checks that the partition you selected contains enough space to hold the installation, and then copies files to the partition. The files are most of those that will become the new operating system.

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.

Edited by porear, 18 November 2006 - 09:41 PM.


#58
porear

porear

    Newbie

  • Member
  • 49 posts
  • Joined 10-August 04
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!

#59
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,669 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

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.


Now I see, :blushing:, just like the setup or whatever is running was using the MOVE command instead of the COPY one.

I guess this is hardcoded.... :angry:, maybe in Setupdd.sys :blink:

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.ozema...eezip/freeware/
http://members.ozema...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

Edited by jaclaz, 19 November 2006 - 08:50 AM.


#60
porear

porear

    Newbie

  • Member
  • 49 posts
  • Joined 10-August 04
You are correct, its acting just like a move.

I guess this is hardcoded, maybe in Setupdd.sys

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.

Another idea, why not letting the setup delete those files and later undelete them?

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....dline_setup.asp

/cmd:
Allows you to specify a set of commands that will execute when the GUI portion of Setup is complete. Typically, this parameter is used to execute a set of commands located in a file called cmdlines.txt. Ex: winnt32 /cmd:cmdlines.txt

and from http://www.quepublis...i...qNum=6&rl=1

/cmd:command_line
Instructs Setup to carry out a specific command before the final phase of Setup.



#61
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,669 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

I think that is an EXCELLENT idea.


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

Chapter I
18. All warfare is based on deception.
19. Hence, when able to attack, we must seem unable;
when using our forces, we must seem inactive; when we
are near, we must make the enemy believe we are far away;
when far away, we must make him believe we are near.
24. Attack him where he is unprepared, appear where
you are not expected.
Chapter V
5. In all fighting, the direct method may be used
for joining battle, but indirect methods will be needed
in order to secure victory.
6. Indirect tactics, efficiently applied, are inexhaustible
as Heaven and Earth, unending as the flow of rivers and streams;
like the sun and moon, they end but to begin anew;
like the four seasons, they pass away to return once more.
Chapter VI
30. So in war, the way is to avoid what is strong
and to strike at what is weak.
Chapter XI
60. Success in warfare is gained by carefully
accommodating ourselves to the enemy's purpose.
65. If the enemy leaves a door open, you must rush in.
Chapter XII
19. If it is to your advantage, make a forward move;
if not, stay where you are.


...and I probably just won the 2006 award for the most off-topic post of the year ... :P

jaclaz

#62
porear

porear

    Newbie

  • Member
  • 49 posts
  • Joined 10-August 04
hehe very nicely done. This thread was about due for a dose of OT :D

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? :whistle:

#63
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,669 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

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.da...mbr/MSWIN41.htm
http://thestarman.da.../mbr/NTFSBR.htm
and here for FAT16:
http://home.teleport...rainy/fat16.htm
http://averstak.trip...dox/bootsec.htm
http://www.ntfs.com/...tion-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

#64
porear

porear

    Newbie

  • Member
  • 49 posts
  • Joined 10-August 04

I am assuming that the volume has two FATs and is FAT16.

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.

Posted Image

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

Edited by porear, 20 November 2006 - 09:26 PM.


#65
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,669 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag
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

:thumbup

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...o...=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

#66
porear

porear

    Newbie

  • Member
  • 49 posts
  • Joined 10-August 04
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. :)

Attached Files


Edited by porear, 22 November 2006 - 09:53 AM.


#67
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,669 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

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

#68
Puggsley

Puggsley

    Newbie

  • Member
  • 25 posts
  • Joined 19-November 06
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.

#69
LLXX

LLXX

    MSFN Junkie

  • Banned
  • PipPipPipPipPipPipPipPipPip
  • 3,399 posts
  • Joined 04-December 05

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.

#70
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,669 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

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.


You might have missed the start of this:
http://www.msfn.org/...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...showtopic=16713

One can later convert the FAT32 system drive to NTFS with the MS utility convert:
http://www.microsoft...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

Edited by jaclaz, 23 November 2006 - 11:09 AM.


#71
porear

porear

    Newbie

  • Member
  • 49 posts
  • Joined 10-August 04
uuuuuuuughhhhhh too much food. :D 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.i...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.computerh...om/undelete.htm

This program / command was designed to only be run in MS-DOS versions 5.0 to 6.22. If you have upgraded to Windows 95, Windows 98, Windows NT, or any other Operating system, this command will not restore any information but may possibly cause additional issues with the Hard Drive if run.


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.

Attached Files



#72
hatsumi

hatsumi

    Newbie

  • Member
  • 13 posts
  • Joined 24-December 03
  • OS:Windows 7 x64

Here are some instructions you may find helpful:

WeetHet USB Boot setup


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 :D

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

Edited by hatsumi, 24 November 2006 - 08:43 PM.


#73
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,669 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

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.


Yep, that's what I was referring to originally, though I most probably suggested a WRONG :angry: 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.sour...ckages/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.partition....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

#74
porear

porear

    Newbie

  • Member
  • 49 posts
  • Joined 10-August 04

....and off I go searching again for the right tool!

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.

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.sour...ckages/gsar.htm

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.

#75
porear

porear

    Newbie

  • Member
  • 49 posts
  • Joined 10-August 04
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? :sneaky:




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users