jaclaz

@snoopy55 The ability to put a pagefile on a USB stick is determined by a number of things (ways the OS "sees" the device). What I find very strange (besides what you want to achieve) is what you report. A "normal" MS NT based OS won't allow having a pagefile on an "external" disk, let alone a "removable" one. To allow this normally a filter driver is used, see here for DiskMod: http://reboot.pro/9461/ http://reboot.pro/9461/#entry86619/ which comes also in a 64 bit version, though tested only on later systems (Vista and 7) AFAICR. jaclaz

No, there must be something being lost in translation (either "human" translation or "batch/program" one). It seems to me like you did everything "right". Myfragmenter provides the LCN (that is Logical cluster number). On your disk a cluster is made by 8 sectors and there is an initial offset of 63 sectors to the volume (or start of the Logical Cluster Number). The myfragi batch takes the LCN and converts it in Absolute LBA, i.e. it converts 769865*8+63=6158983 As well it takes the difference beween Vcn's and multiplies it by 8, i.e. if you run directly myfragmenter -i you should get for that file Vcn=0, NextVcn=78 and the myfragi does (78-0)*8=624 And the file should be 624*512=319488 In drdd you use LBA so you should have start 6158983 and length 624. Since this file is already in one chunk, the result should be already the file. But these seem right: The only issue is that since the myfragmenter uses clusters as "unit", the resulting file might be larger (up to the cluster border) than the original, this shouldn't be a problem for images like JPEG, but it may be an issue with other data formats, in which case you use again fsz to "cut" the file to the exact bytes length you have in Explorer or in a DIR command. Could it be an issue with the initial offset? Maybe the my500Gb.img, being mounted in IMDISK (which ignores hidden sectors/first track) shifts the addresses? (but it doesn't "sound" right) Try doing a test with a file on your "main", working drive and or, try accessing the same file with DMDE, the LBA and LCN should be the same as the ones provided by myfragi. If they are, the only sensible explanation is that the reading of those particular sectors from the "original" disk drive are now failing (while they worked when you made the 134 Gb image.... jaclaz

As a matter of fact nothing really "challenging" . The comparison between a Server 2003 32 bit using PAE with a (say) Server 2008 R2 64 bit is one of those "practical impossibilities" in the sense that I have never seen such a comparison done "properly" (if not for "research") i.e. on comparable hardware, usually you have a several years old machine running 32 bit 2003 Server, and you get a brand new machine, install to it 2008 R2 64 bit and this latter is actually much faster, but how much of it is due to the hardware and how much to the 64 bitness is normally to be seen. I would go further affirming that - often - (and obviously I am making here a very generic statement ) servers need to have a very fast storage subsystem and their performance is rarely connected with how fast is their memory access, but rather on how fast is their storage subsystem. When an actually memory intensive use of the server is needed, the advantage of the 64 bit memory addressing is seemingly more in the "capabilities" than in speed, see this as an example: http://www.dell.com/downloads/global/solutions/oracle_performance_em64t_6850.pdf on page 9 there is a nice XY graph showing how the performance (until a "size limit" is reached) is substantially the same. jaclaz

I don't have the Porsche and I quite frankly cannot see a single reason for using my Toyouta Hi-Lux for moving dirt and yard waste across your property. Of course, if you come over here with your wheelbarrow, I will be glad to give you a chance of showing me how fast you are moving dirt and yard waste across my property. jaclaz

Do you want a more "professional" source? Here you are: http://msdn.microsoft.com/en-us/library/windows/desktop/ee719653(v=vs.85).aspx http://msdn.microsoft.com/en-us/library/windows/desktop/ee719901(v=vs.85).aspx I guess that you need to remove the WIC codec http://en.wikipedia.org/wiki/Windows_Imaging_Component jaclaz

Well, BOTH a Toyota Hi-Lux and a Porsche 911 would be way faster than your wheelbarrow (because they have more wheels). For NO apparent reason, but JFYI : jaclaz

Never thought you were a fanboy, as said there is a number of people that actually needed to have the XP 64 (only they are much less than the actual XP 64 user base) you may well be one of the few, and, like everyone else migrating to the new platform you must have had the same driver issues everyone else had, or you were another lucky peep like JodyThornton is? However, as said, no problem if you hadn't actually a need for it and just fancied it. The usual comparison between Porsche 911 and Toyota Hi-Lux (and a wheelbarrow ) JFYI: http://www.911cd.net/forums//index.php?showtopic=24502&st=12 jaclaz

@CharlotteTheHarlot You are evidently not very familiar with mathematics/economy. You would have to add the question: Are you running Windows 7 or Windows 8? to the list of questions that an underpayed, good willing but technically inexperiened help desk operator in an eastern country will have to ask calling customers . That (and the customer answer after having checked) would increase the duration of the call by 10 to 15 seconds. To that you should add the increased costs for the (non-)training of the help desk operators. And drivers for BOTH 7 and 8? Those represent money, BIG bucks. The new solution under study for HP support for windows 7 is a recorded message to the effect of: One size fits all! jaclaz

Not at all. Simply trying to have things called with their names . Is a 64 bit system more "capable" overall than a 32 bit system? Yes. Is a 64 bit system faster than a 32 bit system? Rarely. Is a 64 bit application running in a 64 bit OS faster than it's 32 bit counterpart? Rarely. Does everyone *needed* at the time of XP 64 a 64 bit system? No, only a very few people in the need of running very high end kind of apps might have actually *needed* one, and they would have had to be very careful in finding supported hardware and their drivers, at the time non-existing or rare or buggy. Does everyone *need* (now) a 64 bit system? No, only a few people in the need of running very high end kind of apps or however doing an "intensive" use of a PC may actually *need* one, the good news being that the issues with supported hardware and their drivers are not anymore a common problem. Is a 32 bit app running under a 64 bit faster than on a native 32 bit system? No. But 32 bit systems cannot access more than 3/4 Gb of RAM.... NO. The limit is given in some MS OS's by commercial/technical choices (NOT architecture limits) as - even without any technical knowledge easily verifiable by checking how most 32 bit Server edition support largely more that that, typically 64 Gb: http://msdn.microsoft.com/library/aa366778.aspx But 32 bit systems running PAE are slower than 64 bit systems accessing memory. Not really, or the differences (comparing very similar hardware) are negligible. But I like to have a 64 bit system anyway. That's good :, and you can have one allright , only you should know how most probably you won't be going to use all the increased potentialities of it when compared to a 32 bit system, and you shouldn't say that you chose it because 32 bit OS does not support more than 3/4 Gb of memory, as this is not the case, an OS vendor has introduced some limits to some of the 32 bit OS's it sells for its own (perfectly logical) commercial or technical reasons. jaclaz

Have a look at one of those CD's with a tool like Isobuster (freeware/shareware): http://www.isobuster.com/ you will like find a number of "sessions". jaclaz

Yep The spreadsheet could look something *like*: By LBA Ext: Lcn: LBAstart: Sects: File: Limit: ROffset: ROffsetB: #1 1 495.625 3.965.063 16 f:\montage\2011-tmp.pds 2.766.950.084 - - #3 2 28.135.076 225.080.671 16 f:\montage\2011-tmp.pds 2.766.950.084 16 8.192 #5 3 48.751.063 390.008.567 32 f:\montage\2011-tmp.pds 2.766.950.084 32 16.384 #6 4 48.797.290 390.378.383 64 f:\montage\2011-tmp.pds 2.766.950.084 64 32.768 #7 5 50.038.742 400.309.999 128 f:\montage\2011-tmp.pds 2.766.950.084 128 65.536 #2 6 26.068.714 208.549.775 128 f:\montage\2011-tmp.pds 2.766.950.084 256 131.072 #9 7 94.098.378 752.787.087 136 f:\montage\2011-tmp.pds 2.766.950.084 384 196.608 #8 8 74.619.826 596.958.671 120 f:\montage\2011-tmp.pds 2.766.950.084 520 266.240 #10 9 95.440.487 763.523.959 152 f:\montage\2011-tmp.pds 2.766.950.084 640 327.680 #12 10 106.615.323 852.922.647 104 f:\montage\2011-tmp.pds 2.766.950.084 792 405.504 #11 11 95.441.871 763.535.031 152 f:\montage\2011-tmp.pds 2.766.950.084 896 458.752 #4 12 48.579.698 388.637.647 24 f:\montage\2011-tmp.pds 2.766.950.084 1.048 536.576 where Roffset= Sects+Previous ROffset and ROffsetB=ROffset*512 The "0" means "copy the whole size" of the following "chunk", you could use instead the exact size of the chunk in bytes, but it only makes more complex the command, i.e. it could be: (by coincidence the second chunk is actually 16 sectors i.e. 8192 bytes in size) jaclaz

But you feel like commenting on them nonetheless, "mostly illogical, but fascinating nonetheless" my good friend Spock would comment . Sure , let's make a list of all applications that crash on a 32 bit OS (as all 32 bit OS are the same and particularly all MS ones and the myriad of version that there are of them all behave the same). You should use 64 bit only systems (and also add some RAM to them), if you happen to easily hit 1.7 Gb oin a browser, the whole point was only that this is not "everyday common" and definitely it wasn't in XP 64 times. jaclaz

Good, another one having not read the given links. I cannot post a direct link to the relevant info, because for *any* reason it is considered "hostile" by MSFN. But I can point you to a related MS KB: http://support.microsoft.com/kb/888137/en-us jaclaz

I am not an expert on this, but it seems like Vista uses the IMAPI 2 to write discs in SAO mode, see: http://en.wikipedia.org/wiki/Optical_disc_recording_modes http://en.wikipedia.org/wiki/Image_Mastering_API http://www.osta.org/technology/cdqa2.htm which is basically a multi-session disk . It is likely that the issue you are having are created by the multiple sessions indexes, lead-in, lead out, etc.. Are you positive that you are using CDRW media (and not CDR) ? jaclaz

As a matter of fact the WHOLE JPEG format is made of "dynamic" fields and it is ALREADY complex enough to parse without the good Adobe guys inventing this "feature" and the other good guys from MS adopting it "mainstrem" not before (as said) having dumbified it, by removing from it the actual useful info about the app that did it and pointing to a non existing site. jaclaz

I said READ the given links (AND links within them) then take your own decisions/conclusions/whatever, only please don't give me the usual "32 bit systems cannot access more than 4 Gb of RAM" or the usual generic "64 bit is better". jaclaz

Good, now you should be able to put (copy and paste or, better import) the contents of the .log into a spreadsheet. In theory you have a "good" or almost good 134 Gb image, so anything (roughly, you will have to make the math exactly) before: 134 GB=~134*1024*1024*1024=143881404416/512=LBA 2766950084 should be already on your image, so in the spreadsheet you order by LBA address and get the chunks that are missing. Now there is the usual doubt about which strategy to use to get the missing data. Basically there are two theories - no way to know which one may give you "better" results, depending on the actual issue one or the oher may work better, or both could work the same, or both could fail: theory of "little by little" <- you just try to get the chunk that you need theory of "greater area" <- you try to get an area of the orignal disk larger than the chunk(s) you need, and then you re-parse this to get the exact chunks Theory #1 is based on the hypothesis that the head going to a given place is more exact" than "passing by", theory #2 is based ont the opposite hypothesys. Of course on a disk that has no issues both would work perfectly, but you never know, additionally datarescuedd has also an option to get sectors in "reverse reading", which sometimes helps. The BAD news are that seemingly, and though fragmented, that particular file seems like being entirely within he first 134 Gb . Which could mean that your image already contains some corruprted sector Try getting all single chunks from the original disk with datarescueDD. Once you have extracted (hopefully) all 12 "chunks", you can re-assemble them by using COPY +, but it is usually more convenient using some od the tools in DSFOK toolkit: http://members.ozemail.com.au/~nulifetv/freezip/freeware/ If you sum the sizes of the chunks in the spreadsheet you get 1072 sectors, i.e. 1072*512=548864 which should also be the size of the file that you see in Explorer or in DIR... So you do: This will create an empty file of that size in bytes. Then you use: dsfi C:\mytemp.dat <offset> 0 <filechunk.dd> which means copy to C:\mytemp.dat, starting from offset <offset> for all it's length (0) the <filechunk.dd> where offset is the offset in BYTEs of the filechunk and the <fileschunk> is the name of the file extracted with datarescuedd, the first chunk with your data should be image[2030112256-2030120448].dd (where obviously 2030112256 is made by the LBA offset*512=3965063*512=2030112256 and 2030120448 is the offset+the length, i.e. 3965063*512+16*512=2030120448) The use of a spreadsheet is advised as it will produce the exact command lines faster and without the risk of typing errors. jaclaz

Good. Try using the attached batch. The output of myfragmenter is expressed in Logical Cluster Number (relative to the Volume) and Virtual Cluster numbers (relative to the file). The batch converts (or attempts to ) those in "plain" "absolute" (i.e. relative to the disk) LBA addreses and Sectors lengths of the chunks or extents. The settings: are already set in the batch for the disk values you have. jaclaz myfragi.zip

Which program/tool (and under which OS) are you using it to write on the disc? How EXACTLY are you using it? If you are using "multisessions" or by any chance the disc become "finalized", you will have NO available space on it, no matter how much data is on it, but since it is an RW, you can make a copy of the files on it, re-initialize the disc and copy back the old and new files anyway. jaclaz

Why should you be (or anyone else for that matters) be wrong, you are reporting your opinion, based on your experience. I guess everyone is happy for your satisfying experience . This doesn't in any way negates how colore's experience was seemingly dreadful , nor my personal opinion that in most cases using a 64 bit OS gives not any practical advantage, or if you prefer is/was UNneeded and - in times of Windows XP - it was actually very rare to find suitable hardware and thus a PITA. My crystal ball - though foggy - tells me that soon someone will post something like: and some other of the usual 64 bit fanboyism, so - as a preventive measure - I will post a couple links: http://reboot.pro/17568/ http://reboot.pro/16544/page__st__25#entry151030 jaclaz

@tomasz86 Last time I checked pagefile.sys was a system file, cannot really remember on NT or 2K. http://ss64.com/nt/attrib.html I presume that you would need anyway to turn the System state to off before being able to hide it (and reset it to System in the "same go"), but the file should be in use anyway and thus possibly allow you not to change it's status.... jaclaz

http://www.nirsoft.net/utils/bulk_file_changer.html That CRAP looks a LOT like Adobe XMP (and you thought that Windows 8 was the bottom of the barrel, didn't you? ) http://metadatadeluxe.pbworks.com/w/page/20792219/Adobe%20XMP There is in theory a field for the specific app that wrote the metadata, but obviously the good MS guys dumbified it by writing UNconditionally "http://ns.microsoft.com/photo/1.0/"'>http://ns.microsoft.com/photo/1.0/" and "MicrosoftPhoto" http://www.exiv2.org/tags-xmp-MicrosoftPhoto.html BTW, see here: http://metadatadeluxe.pbworks.com/w/page/20792236/ExifTool%20import%20function,%20jpeg try accessing: http://www.iptc.org/std/Iptc4xmpCore/1.0/xmlns/ or: http://purl.org/dc/elements/1.1/ and the corresponding: http://ns.microsoft.com/photo/1.0/ It's the senseless "PhotoGallery" since Vista http://blogs.msdn.com/b/pix/archive/2006/08/16/702780.aspx http://blogs.msdn.com/b/pix/archive/2006/08/23/715340.aspx and probably the "enhanced" search too. jaclaz

Nor does the XP one, one can use DOS and WINNT.EXE, the "original" way to install XP from USB (by running WINNT.EXE) is several years old, and actually starts from internal hard disk: http://www.911cd.net/forums//index.php?showtopic=16713 as well there have never been issues in making a WINNT.~BT and WINNT.~LS on another hard disk and transfer them to the machine (still through DOS), but here it is not even clear if the actual Cd-ROM dive is functional.... jaclaz

I would have thought that the migration tool was designed for that: http://technet.microsoft.com/en-us/library/cc722032(v=ws.10).aspx though I have NO idea about it's compatibility with the (IMHO) senseless 64 bit OS's, apparently at least up to Vista they are supported: http://technet.microsoft.com/en-us/library/cc721840(v=ws.10).aspx jaclaz

Hmmm. Try it on a file on another volume (a "good" one, with a working filesystem). For very small files it won't work as they are stored directly in the $MFT, but it should otherwise work (I don't think that there are issues with the "sparse" nature of the underlying file, as it is mounted in IMDISK, you could try using a different mounting tool/driver, but it shouldn't actually matter). Try another tool. Get myfragmenter: http://www.mydefrag.com/SeeAlso-MyFragmenter.html (part of mydefrag): http://www.mydefrag.com/Manual-DownloadAndInstall.html make SURE to use it with the -i switch, i.e. myfragmenter.exe -i F:\my_path\my_file.ext What happens? Also please, when posting the result of a command, post also the EXACT way you invoked it (command line), you did not specify how you invoked GetFileExtents, it could be that you invoked it wrongly (in the sense of having given it a non existing path or whatever)... jaclaz