jaclaz

I don't get it. It seems like a nice experiment, though it makes to me little sense (both in the actual contents and in the way the results are presented ). I used a (totally arbitrary ) standard that sets m as the variable for the offset command and n as the variable for the align command and you used n for BOTH? The allowed values m for the offset command are seemingly: What you have found is that if you use any other value it will be rounded up or down to the next allowed value BUT that there are a few allowed values not listed in the above . Here are in green the above "known allowed values" and in red the "additional ones you found": 32 64 128 192 256 320 384 448 512 1024 2048 Most probably there are more such values in the range beyond 512 (that you have seemingly not explored). Why have you not tested m=32 ? Why have you not tested the three lines I posted? (just to see if theory and practice are the same - by pure chance) create partition primary offset=32 align=4 create partition primary align=4 create partition primary align=32 I am pretty sure about the "create partition primary align=32" : http://www.msexchange.org/tutorials/disk-geometry.html resulting in a partition starting on sector 64, the other two are the ones to check. The allowed values n for the aligncommand are seemingly: What you have found is that there are a few allowed values not listed in the above . But you started with a "not allowed" value of m=160 (which probably results in a 128 ), so I don't think that your results are - if not for the "allowed" values - following a "logic", it is more likely that they are a "side effect" of using such non-standard values (if you prefer a "bug" in the parsing mechanism). jaclaz

You seemingly are a rich man , see the price of these (which should be the "equivalent"): http://www.rrdatatelecom.com/cgi-bin/rrdata/L1167 More of the same "kind" (seeemingly called "card edge 34" or "CE34": http://www.rrdatatelecom.com/cgi-bin/rrdata/CE34M-M http://www.rrdatatelecom.com/cgi-bin/rrdata/CE34F This should be the type you have: http://www.rrdatatelecom.com/cgi-bin/rrdata/L1065 If you have some unused cables (female) they could also be of use : http://www.scienceprog.com/sd-mmc-card-fits-in-floppy-connector/ jaclaz

I would think this is a potential problem then, is it? Too bad because I like the fact that the UI gives information about the disk which means that one can easier recognize which disk is which... Not really, really that's the way *all* tools should behave (when dealing with data recovery). Basically when you hit a bad sector, a "normal" tool will throw an error and abort or "insist" trying over and over on that same (bad) sector (and thus "stall"). A recovery oriented tool will try a few times to read the bad sector (let's say 5 times) then will understand that the sector is actually bad and write to the target a sector full of 00's INSTEAD and continue to the next sector. If there is a bunch of bad sectors in some cases it is advised to avoid also the (say) 5 times try on each of them (which will slow considerably the imaging) and simply "jump" a little bit further (and possibly later trying again that zone "backwards"), that is the idea of the DatarescueDD. jaclaz

Opening a command prompt and typing in it: will give you all the information available (which you should anyway test yourself). The syntax is similar (though not identical) to many other programs that do the same thing, the "archeotype" of them is "dd" see (only to learn some history and possibly to get a quick laugh ): http://reboot.pro/15207/ Basically dd takes a source and copies it to a target based on offset/position/address without caring about the contents. The other programs I suggested you before are either "more suited to data recovery" (they use some specific "strategy" to attempt reading the data in case of difficulty and/or "give up" after a number of failed tries and write to the target a 00ed sector instead of throwing an error) or " Exactly. For "normal" use, i.e. NOT for "forensics" or "data recovery", ignoring some data (which are unneeded for these other than foresics or data recovery scopes) will allow a number of advantages, like faster operation, smaller images, etc. a quick sum up is here: You are welcome, actually the fact that you are "new to the field" is a good thing: it means that you never faced a serious case of data loss in these years . The app Kelsenellenelvian posted a link to seems like solving the issue in a better way as it is reported to be working (for sure) on 7 both 32 and 64 bit. jaclaz

I would say that, more than that, by using Vlite in a business/enterprise environment you would violate its (Vlite's) license . In other words, the whole point is that vlite is ONLY for personal use: jaclaz

Therefore, since BlackArmor Backup makes its images/clones/backups/whatever WHILE THE DISK IS IN USE, it was not unreasonable for me to start wondering whether that software would do what I need to have done. S Well, this is flattering you value a single sentence extrapolated from a post of mine in a thread where the issue is "not installed third party" tools more than a whole manual from guys that since several years (I am talking of Acronis, not of Seagate) are among the "top players" in data backup/disk imaging/cloning. When you actually read the manual, you must have missed chapter 3.1: which seems to me like very similar to what I summed up in post #5. Yep , but you cannot play dumb at will . The average Joe would take what the good Acronis or Seagate guys say on the matter as "the one and only thruth" and happily image/backup/whatever his disks, the sheer moment in which you decide to delve deeper, and doubt their word for it, you will need to get familiar with the minutiae . Red pills are better IMHO, but rabbit holes are deeeep : jaclaz

Well NEVER trust anything or anyone! Do a simple experiment. Check the first sector of both the \\.\PhysicalDrive0 and 1 rawcopy 512 \\.\PhysicalDrive0 C:\drive0.bin rawcopy 512 \\.\PhysicalDrive1 C:\drive1.bin Then physically disconnect the "unbricked disk" and redo: rawcopy 512 \\.\PhysicalDrive0 C:\drive0_2.bin rawcopy 512 \\.\PhysicalDrive1 C:\drive1_2.bin If the setup is what you see in disk management you should get two identical files C:\drive1.bin and C:\drive1_2.bin, a file C:\drive0.bin and an error as at the second attempt there should be no drive0 avaialble. As well, to make sure of the n check in disk management before connecting the "target" drive and after connecting it . jaclaz Edit: ERRATA CORRIGE the rawcopy thingy uses bytes and not sectors as "copylength" corrected in the above from "1" to "512"

Then the partition and the bootsector are seemingly OK. Then a good idea would be to image it. The reference app is Datarescuedd, see here: http://reboot.pro/7783/ You might want to do a few tests with "smallish" parts of the disk , see this for a possible approach: http://reboot.pro/15040/#entry133567 I have no idea if it works ok under 7 64 bit, it should, but cannot say. If you have a XP available it should be "safer" (in the sense of "known to be working") Hmmm, strange. It is possible that there is a bunch of bad sectors (or a translation table in the disk that was cleared during the unbricking) but a failed $MFT Mirror should not prevent the filesystem to be recognized . Once you have the image done, we will see what TESTDISK finds about those.... jaclaz

It is "unusual" in the sense that what you report should be related to BIOS drive order (and the way disks are connected to the actual physical interfaces on the motherboard) and normally first disk in BIOS is the "boot disk" and BOTH the "source" (drive to recover/copy from) and "target" (drive used for cloning/copy to) are attached to it "later". The above is the "normal" setup, when you have a fully working machine and you add to it the source and the target disks. On the other hand, if the "bricked" disk "was" a boot disk on that machine and you added a second disk installing to it a "temporary OS" and after the unbricking you placed the "unbricked" disk where it was before, what you report may be "normal". jaclaz

At first sight there is nothing "wrong" in them. BUT how exactly (under which OS, with which tools) was the disk partitioned originally? The sectors you posted seems like a "normal" XP partitioned (French), single NTFS: #0 07 80 0 1 1 1023 254 63 63 976768002 The data in the bootsector is as well "standard": 3 0003 OEM String: NTFS 11 000B Bytes per sector: 0200 512 21 0015 Media type: F8 248 24 0018 Sectors per Head: 003F 63 26 001A Number of Heads: 00FF 255 28 001C Sectors Before: 0000003F 63 40 0028 Total Sectors: 000000003A384C01 976768001 48 0030 LCN for $MFT:: 00000000000C0000 786432 56 0038 LCN for $MFTMirr:: 0000000003A384C0 61048000 64 0040 Clusters per $MFT record: 000000F6 246 68 0044 Clusters per Index record: 00000001 1 72 0048 Volume Serial: 6424B80A24B7DD6C Which OS are you running/can run? Ideally you should try imaging the disk on a (larger) device as a file, first thing, do you have (or can buy) a 640 or 750 Gb disk? You could check with a disk viewer/editor the presence at the designed addresses of the $MFT and of it's mirror. $MFT is at 63+786432*8=sector 6,291,519 $MFT Mirror is at 63+61048000*8=sector 488,384,063 The first sector of both should begin with "File0" or in hex "46494C4530". jaclaz

Well, no. If it was a "mere" partition copy, it would never have booted from the new disk, you would need anyway to copy (or fix) the MBR and the disk signature - or the connected Registry entries). So, even if it would not be a "whole disk" copy, it would be anyway a "whole disk copy minus the second temporary partition" . jaclaz

No, it's OK, as said it is very likely (though not "granted") that the 32 bit programs will work in the 64 OS without a glitch, but I have a few doubts on the cloning app that you mentioned . According to this: http://www.todo-backup.com/support/tutorial/clone-hard-drive.htm It sounds like even in the "sector by sector" mode the actual partition table OR "indexed in the filesystem sectors" (used space in the above snippet) is involved in the "clone" process. This (forensic version of dd): http://gmgsystemsinc.com/fau/ or rawcopy: http://www.ltr-data.se/opencode.html/ might do (as they have a 64 bit version). If I were you I would try the latter. Something "plain" like: should do, the above uses NOT any "fine-tuning", it will probably take some time (a few hours) to perform the copy. Be VERY, VERY careful in choosing m and n ....they are the disk numbers (as you can see them in Disk Management and/or diskpart, first disk (boot disk) is 0, if you have three disks they will be 0, 1 and 2 be sure to identify correctly which one is the source and which is the target. When cloning a disk drive it is a good idea to make sure that BOTH the "source" and the "target" drives are kept "cool", depending on your setup/hardware, it could be advisable to add a fan to have some additional airflow aroud the disks. The "general" issue with 7 might be that the disk (actually some sectors on it) are "locked", from what I understand this should not apply to a disk that is seen as "RAW", most possibly later in the recovery it might be needed to put the disk "offline", see references here: page__view__findpost__p__1006402 jaclaz

You are very welcome to ask questions , but you will need to be more flexible with your "available tools". I have NO idea IF any of the mentioned software will work: under 64 bit under windows 8 under the two above combined or if they will work "correctly". If I should bet on the worst possible combination one could find for data recovery, I would bet on Windows 8 64 bit . Now, get real . You are going to risk supposedly very valuable data by using "legacy" tools, designed for 32 bit on a 64 bit OS (and this in itself is not "smart" as you rely on the 32 bit subsystem that could have some incompatibilities with "real 32 bit OS) and to this you add the use of newly released OS (and traditionally NO MS OS was EVER found to be stable before "SP1"). While the first would be IMHO a limited risk (but that I would anyway choose NOT on valuable data), the second seems to me like "pure folly" . If you had several YEARS of experience with the tools, then it would be logical for you to test the new OS and environment (on EXPENDABLE data ONLY of course) but without any experience with the tools introducing a brand new OS? Come on.... If you have not available a "good" WIndows NT based system, i.e. a 2K or XP (and possibly NOT Vista or 7 AND definitely NOT 8) then you'd better get a free Linux based live disk, that is known to work. You want either ddrescue or dd_rescue (most distro's will have one of them) and TESTDISK/PHOTOREC are also available in the Linux version on many distro's, Parted Magic is the first one that comes to mind: http://partedmagic.com/doku.php?id=start jaclaz

To be on the safe side you should first thing image the disk. Normally one would image the disk, i.e. save it's entire contents to a file on another (larger) disk. Since you only have other disks of the same size this is not possible, so, as a poorman's solution you could clone (i.e. directly copy sector by sector) the contents of the unbricked disk to the other disk. This is intended as a preventive measure, by having an image or a clone, in case of any possible "mistake" during the recovery procedure you have a "way back". Under windows NT (and possibly a 2K or XP would be "better" than a Vista or 7 because of some added complications with direct disk access in these two latter OS's) recommended tools are: For imaging DatarescueDD: http://www.datarescue.com/photorescue/v3/drdd.htm For cloning : http://alter.org.ua/en/soft/win/bb_recover/ The app of reference is TESTDISK (for partition oriented recovery) or the "companion" PHOTOREC (for file based recovery): http://www.cgsecurity.org/wiki/TestDisk It is very possible that some manual intervention by means of a hex editor will be needed anyway, in any case, if you have ANY doubt in the usage of any of the tools, ask BEFORE doing something that you may later regret . Here is an example of a similar recovery, performed succesfully after the OP used TESTDISK improperly (that should give you a fair idea also of the steps necessary to use it properly) and - if you are in the same situation - give you some hope in the success of a partition based recovery: jaclaz

Not at all competitive . Momentarily irritated by your pickyness on the unrelated thread, yes And the idea was not at all to somehow "intimidate" you and/or prevent you from replying to a question, your post to which I replied was NOT an answer to any question, or at least not an answer to any question asked on that thread, the idea was to highlight the off-topicness of your remark. We both provided a possible solution - of course as different variations - but on a SAME theme, that is/was "booting something else". But - just for the record - no, I would not have needed to create a 2nd partition on the "source" (actually currently booting drive) as I suggested to use grub4dos to boot from a floppy image saved on the same (already existing) partition. On the contrary, one would have needed a partition (even temporary) on the "target" drive, to store the image. The idea was to make the less "intrusion" in the source drive, while having the "target" drive (which is/was larger in size) "free" to be formatted/partitioned as one would like. Still in the idea of an "as accurate as possible" image, since the "source" drive is/was 40 Gb and the target drive is/was 120 GB, I would have (in my perverted mind) used the first 40 Gb of the "target" as "space available" to restore the image and the "rest" as space to hold the image to be later restored to the first 40 Gb. The only changes on the source disk would have been: a single line added to BOOT.INI <- which can be added (and later removed) by using NOTEPAD or any text editor a single file a few hundreds of Kb added to the root of the drive (grldr) <- which can later be deleted allright optionally a second very small plain text file added to root of the drive (menu.lst) <- which can be later be deleted allright a single file 1.474.560 bytes (or less if .gz compressed) anywhere on the drive (the floppy image) <- which can be later be deleted allright Your idea is good as well (and I don't see in it all the defects that you are now listing ) but IMHO it represents NOT an answer to the question, since you modify the source disk (by reducing the size of the current partition and add a new partition to store temporarily the image) the image contents that will be deployed to the new disk will be not the image of the disk"as is", but of the disk as "it will be" after your mods... Since PROBLEMCHYLD didn't use EITHER of the proposed solution (which I repeat are both "valid" and "working") but used his own way (which is as said yet another non answer to his original question but the answer to another question) I would call the result of the game between us a draw or even better a null . BTW, and just to be as picky as I traditionally am, had JorgeA asked originally the actual question he had in mind, that is/was: He would have got a simple "Yes" answer: http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/questions-with-yes-or-no-answers.html and there would have been a lot less key presses, and bytes sent over the internet, and misunderstandings (for these latter ones, please accept my apologies should I have somehow hurt your feelings). jaclaz

Sure , it is designed to do that, as long as you ALSO have a way (typically a CD/DVD and/or a USB device or second instance of OS on another disk) to actually initiate the recovery procedure. I.e. the thingy is installed to "backup" into the "live" system but needs to boot (in order to "restore") from "external" media (as the new disk will obviously be "blank"). A good idea, as always when it comes to delicate things such as backing up and restoring, is: DO NOT trust the vendor/Author of the tool DO NOT trust what a guy on a board says DO NOT trust yourself (in the sense of not trusting the presumed familiarity you have with the tool, the way you understood it should be operated and/or the way it works or it is advertised as working) actually get a "new" disk and simulate the backup and recovery process BEFORE disaster happens and see if the result is what you expect If you had actually READ the manual for that thingy: http://www.seagate.com/staticfiles/blackarmor/userguides/BlackArmor_UG.pdf You would have probably found out most of the concepts I briefly summed up. The biggest "risk" with tools like that one (which can do several types of operations/different kinds of backups/images) is the actual way it is used, if you prefer there is a risk of a PEBCAK . AFAICT, it represents a "good" software, though I personally do not like that kind of software (like any other similar software that "hide" the complexity of operation behind a "few click away" APPARENT simplicity) and I prefer to use simpler (most people would call them "more rudimental") software/tools. In a nutshell: Can it do it? Yes. Will it do it? Cannot say. Will it do it when used by you? Cannot say even more.... jaclaz

Whether Microsoft forbids its use or not is totally irrelevant, as well as "MS legal standards" are, something is either legal or illegal according to Law, no matter what MS thinks about it, your local Laws may (usually slightly) differ from another country's ones, but the "opinion" by the good MS guys is irrelevant "everywhere". The question would be - in case - whether MS forbids it AND they can actually legally do it (i.e. if forbidding it is legal or not). If hypothetically they would actually forbid it BUT had no legal (nor practical) means to enforce that, even a positive answer to first question would be meaningless. The answers are anyway NO and NO and no grey areas of sort. You acquired a valid license to use a thing called "Operating System" that is an assembly of a number of separate (or separable) apps/programs/tools. (BTW, specifically also the fact of calling Vista an "Operating System" may be debated ) Let's say that - by mistake - you delete NOTEPAD.EXE or PAINT.EXE. Would this mean that your OS license is made invalid or illegal? Naah, the most they can say is that they won't provide support for your modified OS (which is good since they won't provide a good one even for your "untouched" OS ). They could also decline any responsability for the lousy text that you use notepad to type, but since they already declined any and all responsabilities for anything that the OS (or you through the OS) may ever do or fail to do, this is also allright, they could even want to keep distant from the artwork you produce in paint (or in another program that you use instead of paint), but that's all. jaclaz

Well, most probably "align=4" is used (instead of "align=32"). The result shoudl be the same. It seems like the "align=4" implies "offset=32", i.e. it actually means not "align to 4 Kb" but rather "align to 4 Kb at first multiple equal or beyond 32 Kb". The "full syntax" is something like: where m=32|64|128|256|512|1024|2048 and n=2|4|8|16|32|64 Result being that: all have the same result. It is very possible that the diskpart script (IF diskpart is used) is inside a compressed archive of some kind, yes. jaclaz

Which was actually the SAME one I had proposed LONG BEFORE you did, i.e. booting to "something else" Compare: with: and I can assure you that the suggestion I made (BEFORE yours) is as valid and possibly much simpler, and there are possibly several more very good alternatives to both. BUT, this thread is not the one where we discuss what PROBLEMCHYLD could or should do in order to solve his problem, this thread was started by JorgeA that asked a question about two statements (BTW perfectly valid) that submix8c and myself did in that specific thread and by taking it out of context managed to derive from them a doubt that needed to be cleared (the possibility to have a "good enough for bare metal restore from within an INSTALLED THIRD PARTY TOOL and a running XP). Your nice suggestion about a not installed third party tool in order to solve PROBLEMCHYLD's issue has obviously no actual relevance on a question about an installed third party tool used in another context. To try and clear the doubts: "third party tools" (NOT INSTALLED) do exist that can do a "bare metal recovery" <- from a "non-live" XP system "third party tools" (INSTALLED) do exist that can do a "bare metal recovery" <- from a "live" XP system there are ways by combining "third party tools" (EITHER INSTALLED or NOT INSTALLED) with built-in tools like cdob suggested on the referenced thread (NTBACKUP) <- from a "live" XP system jaclaz

There is nothing "wrong" in your partition table. The first partition starts on sector 64 (which IS CHS 0/1/2) and ends beyond the CHS limit (and thus CHS is at it's max values 1023/254/63). The second partition is entirely beyond the CHS limit ad thus it has CHS values 1023/254/63 1023/254/63). Yes, we can debate if the second partition should be 1023/0/1-1023/254/63 instead, but it won't make any difference in 99.99% of cases. You have clearly a "missing piece" in the puzzle . Any address BELOW the CHS limit (in this case of 255/63 geometry) aroung 8Gb or 1024*255*63*512= 8,422,686,720 bytes MUST be represented BOTH in CHS and LBA addressing. As a matter of fact ANY address MUST be represented along BOTH the addressing methods, the only difference is that for partitions extending beyond the CHS limit, the CHS address resolves to "a suffusion of yellow". How exactly did you get the 64 sectors before alignment? Most probably just like Tripredacus did here: though "somehow" using an "align=32" with diskpart or using one of the "disk manufacturer" Advanced Format formatting tools designed for XP jaclaz

Hmmm. The general idea is to ask for help BEFORE writing anything TO the disk. There are no "magic ideas" , there are only a few "common ideas" , that are actually procedures to attempt recovering the data . Mind you it is very possible that by using an UNsuitable tool in an UNsuitable way, even if the firmware unbricking procedure was successful you effectively corrupted the disk contents beyond any possible recovery . What you should do now would be: STOP fiddling with the disk make a dd-like image of it start a new thread asking for assistance in the recovery An example of the procedure involved is given here (and links within): jaclaz

Just for the record: Antenna on the Cheap (er, Chip) http://www.oreillynet.com/cs/weblog/view/wlg/448 Spanish: http://web.archive.org/web/20080701025639/http://www.selui.com/wireless/antenapringles.html Spanish double (and USB ): http://carzel.wordpress.com/2006/01/03/antena-casera-para-wifi/ jaclaz

I guess we are always around the same terminology issues. Cloning. Imaging. Backing up. Let's see if I can explain the basics. A clone is an EXACT, byte by byte, copy of a disk (normally whole disk). If you prefer there is NO way to distinguish the copy from the original. (set apart the actual hardware disk serial/make/model/capacity). An Image (a "real" or "forensic sound" or "dd-like") is the same as above, stored *somewhere* and that once deployed to a disk the target will become a clone (again No way to distinguish it form the original). Is such a "forensic sound" image (or the "clone" that you can create directly or through dploying this "dd-like" image) needed for *everything*? Certainly not . It is NEEDED; VITAL for: forensics data recovery whatever that requires an EXACT copy For other uses (such as "bare metal" recovery) more than a few things can be removed from it, an incomplete list being: unused sectors (no matter if actually 00's or simply unindexed space) slack space (see here for a NTFS oriented list) : http://www.forensicfocus.com/Forums/viewtopic/t=9374/ pagefile.sys (if any) hyberfil.sys (if any) temp folders contents and more generally caches, histories, cookies, etc. (usually) hidden sectors .... So, if we put the whole disk at 100%, a clone or a forensic sound image will be 100%, while an image done for other scopes may be anything between a very low value (for an almost empty disk) up to 99.99% (but NEVER reach 100%), more likely it should be at something like max 70%. Then there is another issue, the WHEN. A clone or a forensic sound image are made rigorously OFFLINE at a given date/time. Immediately after (and until you don't boot either the original or the copy/clone) they are IDENTICAL. Things like last time accessed timestamps are preserved. A more "normal" image CANNOT be made ONLINE IF NOT through using the Volume Shadow services (or equivalent third party approaches/methods). What the Shadow copy does is to create a "temporary" unchanged version of files. So what you copy is not actually what "is" on the system, but what "was" on the system. Since it is called Volume Shadow, the object is the Volume (and NOT the disk), so a solution (BTW Third Party) such as DriveImageXML is NOT a disk imaging solution (because it is a drive or volume imaging one) and while "enough" for many purposes it is NOT enough for "bare metal" recovery and an image made with it needs to be "integrated with some other data/through other tools, see: http://www.911cd.net/forums//index.php?showtopic=22984 A backup is - generally speaking - meant for DATA (not for disks, nor for drives or volumes). Just like the above described "simplified image" it needs to be integrated with some other data/through other tools (evidently more additional info is needed when compared with a Volume image). Summing up: CLONE=deployed dd-like IMAGE dd-like image = 100% or WHOLE DISK (including EVERY sector of the disk and thus all Volumes/Drives and all info external to Volumes/Drives) ACCURATE Shadow Copy Image=70% (single volume disk) INACCURATE needs additional (very few) info and or tools for "bare metal" use (info external to Volume/Drive) backup =50% (say) VERY INACCURATE needs additional (not very few) info and/or tools for "bare metal" use (info external to Volume/Drive AND info about Volume/Drive) This said, there all all shades of grey, just as an example this nice tool (severaly misnamed as XXCLONE) does NOT "clone" but provides an "intermediate" approach: http://www.xxclone.com/ But the original question was "without third party tools". Some further considerations are here (hardware based cloning): jaclaz

Just for the record the snippet posted by rulman is simply the same as the one dariods posted, only using (0xFF) instead of (hd32) for the vitual CD-ROM, written in a more complex "conditional" way. jaclaz

NO. "Bricked" is a highly specialized technical term ( meaning that the device CANNOT BE ACCESSED at all. If it is accessible (and up to 57%) it is not "bricked" and not necessarily has an issue with the arm not being able to move beyond 57%, it could well be a (smaller or bigger) bunch of bad sectors. This said, yes , *somehow* the actual device has failed, or is failing and it is not worth (being no valuable data on it) to lose any time to understand what is going on, if not for "fun". It is much easier and safer to get another one. In any case if the "fun" choice is made, first thing is to run the hard disk manufacturer tests on it. Happy you like it , though it is specifically or no or little use, it is simply a poor man's kind of FDISK (and nothing more). jaclaz