jaclaz

I still don't get it. And however never seen something like you describe (I mean hundreds of such 0 bytes files). I still don't understand WHY you call them backdoors or zombies or insist on some kind of conspiracy theory. It is either a bug or a mis-setting somewhere. The article you linked to is seemingly about NTFS (and may or may not be connected with FAT32) . What SP level is that Windows 2K? What happens if you disable indexing? (it is mostly unneeded/unuseful anyway) What happens if you just run UNLOCKER on the file(s)? http://www.emptyloop.com/unlocker/ What if you just use another shell instead of Explorer? The pagefile thingy is an alltogether different issue. As you were already told (actually only "hinted toward doing" ): set the pagefile settings to NO pagefile. reboot delete both the C:\pagefile.txt and the D:\pagefile.sys (if still there) set the pagefile again to a fixed size, say 1.5 Gb on the "D:\" drive only see if the pagefile.txt is recreated on C:\ (before running ANY program and having disabled or autostart ones) I suspect that something else -and not Win2K in itself creates that file, as I have used various windows 2K installs for years with a pagefile.sys on a different partition (on same or other disk) and never a "pagefile.txt" file was created anywhere. jaclaz

Topic title edited. Please do review Rules: http://www.msfn.org/board/index.php?app=forums&module=extras&section=boardrules Particularly #1.a This section is about INSTALLing FROM USB. (i.e. the XP and/or 7 on the USB stick are XP or 7 "setups", if you are looking for RUNning XP or 7 from USB or installing them ON USB you are in the wrong place) Is this what you want? If yes, READ the stickies, particularly this one: As always, rather than going for all and everything at once, start with a single item, get familiar with the tools, then add the rest one by one. jaclaz

Well, that's a can-of-worms I'm saving for later. I can always hope NTLDR will work, until proven wrong by a test. But first we must know whether the boot sector will find NTLDR, to give it a chance to work (or fail)... Why it shouldn't work? I mean NTLDR does work on a "normal" FAT12 floppy, I don't see any "normal" reason why the bootsector shouldn't find NTLDR. Making NTLDR based floppies to boot machines with a corrupted NTLDR or BOOT.INI is (was) a normal task: http://support.microsoft.com/kb/305595/en-us http://www.xxcopy.com/xxcopy33.htm jaclaz

I don't get it : Are the complete set of utilities (and instructions) to create such a .iso available or not? Or are they available only for sale? I guess that noone will ever be willing to buy your tools unless they know they do exist and what can be done with them. For the record, my original idea was that of using, just like we have now for 1.2, 1.44 and 2.88 Mb floppies a whole set of "increased size" floppies of "fixed size", like the mentioned here: http://www.911cd.net/forums/index.php?showtopic=11096 Something along the lines of: 3840 5760 8100 ... .... 36 Mb @dencorso Your method, just like mine, tells me (if it was needed) that you are using a truncated image, and not a sparse one. The (small) advantage of DCOPYNT is that you can avoid making the subtraction and just supply the geometry of the target image, 1024*2*36. Another method would be using the dsfok package: fsz full36Mb.img 37748736 dsfi full36Mb.img 0 0 Fd-36Img.IMA The "full" image compresses in 7-zip to 6035 bytes. Do you think, for the sake of saving 6035-708=5327 bytes of bandwidth, that using the truncated image is convenient?

Yes, my bad corrected in previous post(s)) jaclaz

It would be a start, to find a way to reproduce the three .iso's easily (with a populated image). If you could create three .iso's with the given superfloppy sizes and freedos it would be perfect. If you check the given before link: http://reboot.pro/9916/page__st__28 you will see that using the simple, alternate approach, and as long as we want to only populate the superfloppy image, we can simply use the "header" of the .iso file in conjunction with a "populated image". The "rest of the CD" we will find later a way to populate, if we can reproduce the "header" with mkisofs + (if needed) a few hex edits via batch, rest of the CD should be a "piece of cake" . jaclaz

Is running in "batch mode" SIW to create a report suitable? http://www.gtopala.com/ or SIV? http://rh-software.com/ (mind you I have no idea if either of the above can gather the info you need/want ) jaclaz

Hopefully fixed: the "<=" and "=>" issues the [TAB] issue the two PAUSE (leftover from tests) I don't think the batch is particularly CPU hungry, I presume is the "normal" problem with CMD.EXE (or if you prefer Command Prompt). On my PC running split_inf.cmd raises cpu's usage to around 40%, with peak at around 55% The poorman's way for similar problems has been traditionally that of editing the settings in the \Windows\_default.pif, but cannot really say if it affects "pure batch" execution. (and anyway it rarely does *much* difference) You may want to experiment with : http://mion.faireal.net/BES/ jaclaz split_inf_3.zip

Something has got lost in the movements forward and back of the posts between the two three topics. Just for the record and for reference, here is the "Superfloppy one": And here is the "LS-120" one: http://www.msfn.org/board/topic/151957-ls-120-superdisk-drive-under-win98-and-dos/ This (partly) remained on the "wrong" thread: page__st__11 After crashing Nero with some very long Directories, I wrote my own set of CD Writers / ISO Builders. Adding El Torito support was simple. A manual option lets me force Type 0x03 rather than 0x04 for the Boot Image when using Images between 2.88MB and 36MB. I see. Is this app (or set of apps) available? If yes, can you post a link to it? Or is it for "private use"? If yes, can you attach a couple of generated (empty, or with a few redistributable files in them) .iso's? Hex editing a built .iso to set a byte to 0x03 instead of 0x04 is not a problem, but I would like to have an "universal" solution, such as mkisofs may provide. @dencorso Since you are also on this band-wagon and you are in the "make queer filesystems trade", can you prepare three empty superfloppy images sized EXACTLY: I seemingly cannot download the image you posted, but common sense tell's me that no matter how much sparse you made it, it cannot be 708 bytes... (an upload problem? ) ->correction, I managed to download it, now what do you propose to "un-sparse" it? BTW, it should not be a "sparse" image, but rather a "truncated"one. I would use DCOPYNT : http://www.winimage.info/forum/viewtopic.php?f=3&t=3429 http://users.pandora.be/jbosman/applications.html In any case a "normal, non-sparse, non-truncated" image, if empty, will compress in 7z to a few thousands byte.... I will gladly do the experiments with mkisofs to reproduce..... @all Only seemingly off-topic, I find this simplified approach very, very smart: http://reboot.pro/9916/page__st__28'>http://reboot.pro/9916/page__st__28 the whole thread may contain useful info: http://reboot.pro/9916/ jaclaz

Sure they do not, as the DOS and Windows we are currently using were all made AFTER the "invention" of types 04, 06 and 0C 0E, this is IMHO the same "side effect" as the "large Sectors vs. Small Sectors". If you try: DOS <3.3 DOS 3.3 DOS 4.0 DOS <=6.22 DOS >= 7.0 on a set of 01/04/06/0C0E partitions, your mileage should (and will) vary I think that in common language we could consider: FAT12 an ancestor of FAT16 FAT16 04 a sub-set of FAT 06 FAT 16 06 a sub-set of FAT 0C 0E Then draw a line around 1995 and say that everything coded after is accessing *any* of the above in the same way (which allows for some of the tricks we are discussing). As I see it, trying dencorso'S image in DOS 3.3 should fail, as that version of Dos should know nothing about "Large sectors". jaclaz

As long as you comply with my Careware License , yes, of course : http://jaclaz.altervista.org/Projects/careware.html but - as said - at the moment we are very little beyond the "proof of concept" stage. Can you assemble together a "fake" update .inf file with all the lines that you find needing manual correction (i.e. the ones that result as "different" in the re-joined file? This way I can have all in one source the "problematic parts" and test the batches more easily.... IN other words, if you could manually assemble a fake "difficult" file, it will be faster for me. jaclaz

Exactly I may be wrong, but the actual fun in using batches to automate things is to actually automate them. Actually it simply "dedupes" the index of sections, so that each "split" file is only processed once. I'll check. Checked, they are stoopid [TAB]'s. Will add. Yes: ::Final adjustments to be run ONLY once ::run Once ::Replace "==" with a dummy string "§#§" CALL :run_gsar :x3d:x3d :xa7:x23:xa7 jaclaz

Well, you can dedupe the [1ndex] by processing it with FEDIT. Try the attached join_dedupe_inf.cmd instead of join_inf.cmd, I modified it a little bit to create (hopefully) a deduped [1NDEX] fie (actually called [2NDEX] ): ::BEGIN MODIFIED ECHO [DUMMY_SECTION]>%Split_dir%[2NDEX]%Source% FOR /F "skip=2 tokens=1 delims= " %%A IN ('FIND "[" %Split_dir%[1NDEX]%Source%') DO ( SET string=%%A SET string=!string:[=! SET string=!string:]=! ECHO Processing %%A.... Fedit -f %Split_dir%[2NDEX]%Source% -add -once -create -l "dummy" -s "!string!" Fedit -f %Split_dir%[2NDEX]%Source% -rem -l "dummy" -s "!string!" ) Fedit -f %Split_dir%[2NDEX]%Source% -rem -l "[DUMMY_SECTION]" ECHO. ECHO. ECHO TYPE %Split_dir%[2NDEX]%Source% ECHO. TYPE %Split_dir%[2NDEX]%Source% ECHO. FOR /F %%A in (%Split_dir%[2NDEX]%Source%) DO ( ECHO COPY /B %Work%+%Split_dir%%%A%Source% %Work% COPY /B %Work%+%Split_dir%%%A%Source% %Work% ) ::END MODIFIED But the problem I see in "real life" is the order in which you copy together the single .inf files. Wouldn't it be possible that a newer update line is overwritten by an older one (if by chnace a file is copied in the "wrong" order)? I will add the <= and >= provision. jaclaz join_dedupe_inf.zip

@dencorso As often happens, yes and no. Remember the CHS/LBA issues on 2K/XP bootsectors? I guess we are simply LUCKY that it doesn't applies to FAT16 bootesector code. On a side note, VDK without a .pln file descriptor will default to 64/32 anyway, and 2K/XP will use LBA data anyway. @multibooter Those two difference are OK and *somehow* "logical". The one at offset 0x1C is sectors before (or "reserved sectors"), in your snippet it has a value of 0x00000000 and 0x00000020, i.e. 32. The one at offset 0x24 represents "drive number" and is 0x00 in floppy and superfloppy (F0) or normally 0x80 (aka drive 128) on HD (F8). If you compare the bootsector of the image dencorso posted, you will see that it has at 0x15 F0 whilst your snippet has F8. Basically GRDUW seemingly *somehow* transformed the "superfloppy" into a hard disk volume, maybe (or maybe NOT) connected to the "partitioned type" of ZIP disk. jaclaz

1. other two "exception" that need to be taken into consideration in the batch 2. Good. 3. Hmmm, don't think it is very productive, but the fact that the batch worked (though slowly) on a 250 Mb files is good news , it means that there are no strange "overflows" or something the like 4. The "ECHO OFF" line is good (actually "bad" ) news, it means that the variable that was supposed to be echoed got a null value. I need to have the .inf on which this happens, as it marks the place where the problem is. (just like #3 in previous bug report) If you use your "inappropriate" way depicted in #3 above, and, once you create the "original" BIG MERGED file you apply to it the splitinf.cmd, then go to the SPLIT_whatever directory you should be able to process the single section files, but I don't see how by sorting them you can know which one is the line relative to the single update .inf. jaclaz

@dencorso Good. Everything seems more clear. The big difference in calculations was the 1.5 bytes (FAT12) vs. the 2 bytes (FAT16) I still think though that *somehow* using the "large sectors" field represents cheating and exploiting some kind of deficiency (or unintended feature) of the filesystem drivers/whatever. I mean, most probably,and as rloew just confirmed, the driver/whatever is the same for FAT12/16 and the code somehow reads "large sectors" if "small sectors" is 0 no matter the "declared" FAT12 filesystem, whilst it strictly uses the 1.5 bytes depending on the same "declared" FAT12. Running chkdsk on the mounted image gives 3070 clusters, which seems right (and entirely addressable). We have: 1 = bootsector 9+9 FAT tables 512/32=16 Root directory 1+9+9+16=35 sectors that count anyway as one cluster So there should be just one cluster (plus the "spare" sectors above 64-35=29) that are not in any way "addressable". But if you use 10 sectors per FAT, I see no drawbacks, and you get an entire additional cluster addressable! @rloew Sure, the 01/04/06/0C 0E were only to "identify" different "versions", and their respective limits (that were "overtaken" by the new filesystem drivers/whatever). If you don't use mkisofs, what do you use to create a .iso? jaclaz

Yes, the image is non-standard, I have similar problems with dmde. I get: Filesystem: FAT12 Bytes per sector: 512 Sectors per cluster: 64 Reserved Sectors: 1 Root dir entires: 512 Total sectors: 196608 Sectors per FAT: 9 Start offset: 0 Then I get a "Total sectors number was decreased to fit the device" . A quick look at it with Tiny Hexer (+ my BSview structure viewer) tells me that it has a 64/32 geometry (correct for a ZIP drive) and has a "Large sectors" value of 196,608. Most of the difference between FAT12 and FAT16 should be that the sectors number is at offset 19dec, the so called "Small type sectors" in a FAT 12 (thus allowing a max number of 4 bytes, i.e. 65535 sectors x 512=33,553,920 bytes actually a few less) whilst in FAT 16 (06 and 0C 0E type, NOT 04) offset 32dec can be used (for volumes bigger than 32 Mb), the so called "Large sectors" , see also here: http://reboot.pro/5660/ So at first sight it seems like a "hybrid" FAT12/FAT16 filesystem Or maybe better put, it is a FAT 16 filesystem (06 or 0C 0E) "labeled" as "FAT12". Having only 9 sectors per FAT should mean that as soon as you fill the image with files there may be a problem, even with 32 Kb clusters. 9*256=2,304 2,304*32,768=75,497,472 the default for that size being around 200 (with clusters sized 2K) 200*256=51200 51,200*2,048=104,857,600 See also this: http://reboot.pro/13466/ jaclaz

The "old type" had a pre-impressed cross on the top, they are normally not SMD. This acted as "safety" or "pressure release" valve to avoid defective ones to actually explode. The SMD ones leak (when it happens) on the bottom, never on the top: http://www.repeater-builder.com/motorola/spectra/spectra-caps.html jaclaz

I don't want to be a nuisance (or not more than usual ) but could you share: the EXACT size in bytes of those? an example mkisofs command line to build such a super-floppy .iso? (or some reference to the above if available) Any reason for the 32K sized clusters? It should be 2K: http://support.microsoft.com/kb/140365/en-us and it really should be FAT16. Or am I missing something? jaclaz

It seems like the FD32 uses a ZBR (Zone Bit Recording) and PRML : http://www.storagereview.com/guide/dataPRML.html As always happens there are contrasting info, see this: http://slashdot.org/story/01/02/06/1916200/Forget-SuperDisks----Try-32MB-On-A-Floppy The actual "right" data should be this one: http://rays-place.dyndns.org/Extras/PCTechGuide/16storage.htm The time frame is also debatable. See page 13 of this: http://frpcug.org/k-byte/Kbyte03_04_01.PDF It seems to me like the drive was available in 2nd quarter of 2001, but apparently it was initially only OEM. This sheds some more light: http://translate.google.it/translate?u=http%3A%2F%2Fpc.watch.impress.co.jp%2Fdocs%2Farticle%2F20010131%2Fpana.htm&sl=ja&tl=en&hl=&ie=UTF-8 As it gives a link to original product pages: http://translate.google.it/translate?u=http%3A%2F%2Fweb.archive.org%2Fweb%2F20010602074703%2Fhttp%3A%2F%2Fwww.pcc.panasonic.co.jp%2Fp3%2Fproducts%2Fdrive%2Fsuperdisk%2Flkrf240uz%2Findex.html&sl=ja&tl=en&hl=&ie=UTF-8 http://translate.googleusercontent.com/translate_c?ie=UTF8&rurl=translate.google.it&sl=ja&tl=en&twu=1&u=http://web.archive.org/web/20010305113345/http://www.pcc.panasonic.co.jp/p3/products/drive/superdisk/lkrf240uz/fd32_1.html&usg=ALkJrhhfSf3FWqC4g3809zcnbq1HxU9TZQ and to this "media" page: http://translate.googleusercontent.com/translate_c?ie=UTF8&rurl=translate.google.it&sl=ja&tl=en&twu=1&u=http://web.archive.org/web/20010418053908/http://www.pcc.panasonic.co.jp/p3/news/128/index.html&usg=ALkJrhjJmJfJ2icU0gcWfs7Jqcm7k_2EcQ that actually contains links to the various drive models. I guess we need a (paid ) account to get this full text: http://ci.nii.ac.jp/naid/110003688595 http://sciencelinks.jp/j-east/article/200110/000020011001A0346381.php to learn something more. Just a guess on my side, but probably the actual first tracks looks (very loosely) something like: =----------- with the first sector (or maybe whole track) of normal "width and length" (i.e. compatible with a 1.44 MB floppy one) and all the other ones thinner (and probably shorter) jaclaz

What you might not have suspected is that you have much thinner tracks (and 777 of them) apparently: http://everything2.com/title/FD32MB the actual width of the track seems like having been copied and pasted wrongly, this (German) source looks like more reliable http://www.tecchannel.de/storage/komponenten/401752/test_panasonic_ls_240/index6.html jaclaz

OT but not much maybe this thingy here works (not "as is" but as a Registry key) on 9x/Me too? http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=14149 jaclaz

Yes, NO LS-120 can, to my knowledge. The "FD-32" technoloigy (whatever it is) is inherent to the LS-240 and NOT to the LS-120 (another old announce): http://www.neoseeker.com/news/994-que-ls-240-superdisk-external-drive-announced/ and from the mouth of the wolf: An actual PDF for the QPS USB version: http://web.archive.org/web/20011225004413/http://www.qps-inc.com/products/ls240.pdf where the feature is present and the actual manual of the LS-240 from Winstation SCSI version: http://web.archive.org/web/20040401092201/http://www.winstation.com/PDF/SCSI%20SuperDisk/sls-240/SLS240_Manual.pdf where the feature is NOT. BUT http://web.archive.org/web/20011218095613/http://www.winstation.com/Superdisk.htm "Definite proof": http://www.informit.com/articles/article.aspx?p=339027 jaclaz

LS-240 only: http://panasonic.jp/support/p3/st_others/download/index.html (japanese, but clear enough to understand that it is a LS-240 only feature) However: http://www.itreviews.co.uk/hardware/h309.htm jaclaz

I doubt it. There is nothing that can differentiate the two sections in themselves. With the "Install XP from USB" consolidating Sections (with FEDIT) did not produce any unwanted effect, I can also mantain them "separate" by temporarily renaming them, but as I see it it would be philosophycally wrong. I would keep the current (see attachment) consolidating approach and, once we will have solved the actual merging of two files, you will need to test if it works (as it should) with no duplicate sections. Issue #3 was caused mainly by a question mark "?", which now is fixed. The new version should work allright with the 4 mentioned .inf's, try with some other ones and let me know.... jaclaz split_inf_2.zip