jaclaz

Yes, gdisk is command line only, but I wonder what would be its use in the context of "Windows 98 drivers back disks" , you must be talking of "another" gdisk. jaclaz

No idea whether any of those tools will show the GUID (maybe selecting the partition and viewing properties)? I would use gdisk : http://www.rodsbooks.com/gdisk/ and make sure that it sees it as "ef00". jaclaz

Maybe, just maybe, the (stupid) MS tool wants a "canonical" setup, complete with the MSR partition (ad possibly the mysterious second recovery partition)? Or maybe it is the order of the partitions that affect the result, but I doubt it. You posted a screenshot of a tool I am not familiar with, normally the "boot" EFI partition shoudln't be a "GPT (Data Partiton)" but rather a "ESP", of course every tool will call it slightly differently, but it is entirely possible that the GUID/type of that FAT32 volume is not correct (that would be an error that might lead to "Failed to retrieve system partition NT path" (remember that MS calls System what anyone else calls boot and viceversa). Check the actual GUID of that partition, it must be 2C12A7328-F81F-11D2-BA4B-00A0C93EC93B", see: https://en.wikipedia.org/wiki/EFI_system_partition jaclaz

Well, if you booted in UEFI mode, there is a "UEFI" tab in BootIce, if you click on it and then on the button "Edit boot entries" you will open a window looking like: which doesn't seem to me as needing a manual to understand the functioning. or see around 9:35 of this video: jaclaz

Well you can still have BOOTICE (free and GUI) or use efibootmgr from any "live" Linux distro. BootIce can be found also on reboot.pro (but right now it is down) , get it from Softpedia: https://www.softpedia.com/get/System/Boot-Manager-Disk/Bootice.shtml What you changed (just so you know) are some data in the UEFI NVRAM, so loosely yes, they are "in BIOS". jaclaz

Get the wget from the page I posted (and NOT from any other place): https://eternallybored.org/misc/wget/ The XP version I used is 1.19.4, (I posted with a typo before, it is not 1.9.4) Current Windows Vista+ is 1.20.4. If you actually ran 1.11.4, it is WAY OLDER and very likely has not the feature that was added to it in 2015. jaclaz

It must be a heck of an interference to affect a whole node/neighborhood, if you see in a near house something *like* this: that is likely the culprit jaclaz

There is no such thing as "Linux boot menu". The boot menu is what the bootmanager loads, very likely you have GRUB2 as bootmanager/bootloader. And of course you are not dual booting Linux and Windows 10, you decide if you want to remain generically vague (i.e. Linux and Windows) or if you want to detail which Linux distro AND version it is besides Windows 10 LTSB. More generically, if you actually have GRUB2 as bootmanager, you should be actually preoccupied of the Linux updates/upgrades, as most times they do run an "update-grub" command that actually rebuilds (or rather attempts to rebuild) the GRUB2 configuration file (which is usually grub.cfg). If you prefer, the grub.cfg menu (which is very likely what you see when you boot) in GRUB2 is not "static" and is generated (at install time and re-generated with the grub-update command) starting from a set of "base" files. Depending on the EXACT way the GRUB2 has been installed and on the contents of these files, and on the EXACT distro/versions of the Linux distro you are using, this (stupid) auto-magic regeneration may work or it may not. Most of the times it just works, of course, but when it doesn't you'd better have a plan B. Having a backup of the "current" grub.cfg is of course obligatory, but you will need to get familiar with the (complex) mechanism of grub.cfg (stupid) auto-generation and also IMHO get familiar with a few needed GRUB2 commands, as if for whatever reasons the grub.cfg is not found or it has been automagically updated and the update didn't work you will find yourself incapable of booting and stuck at a grub-rescue> prompt. Here is an exceptionally good tutorial: https://www.dedoimedo.com/computers/grub-2.html You want to make sure that either there is a directory corresponding to your Window install or that the provisions for it are inside the 40_custom one, but you should learn also how to boot both the Windows and the Linux from a plain grub-rescue> prompt via a sequence of commands, and - adviced - have handy a copy of the SuperGrubDisk: https://www.supergrubdisk.org/ https://www.supergrubdisk.org/super-grub2-disk/ just in case. jaclaz

Maybe it is the way the Wayback Machine sends the original file/date/time. I tried the: https://web.archive.org/web/20190726124532/http://download.windowsupdate.com/c/msdownload/update/software/secu/2014/09/windowsserver2003-kb2972207-x86-ita_d5cbff29878fc957eae4b256f167918417a88e2d.exe Actually I tried the http link : http://web.archive.org/web/20190726124532/http://download.windowsupdate.com/c/msdownload/update/software/secu/2014/09/windowsserver2003-kb2972207-x86-ita_d5cbff29878fc957eae4b256f167918417a88e2d.exe With good/ol' Net Vampire 3.3: https://www.fileplanet.com/archive/p-43170/Net-Vampire-3-3 and it couldn't fetch the original date BUT looking at its log : the needed info seems to be actually transferred. Now all you need is finding a tool that actually parses the info in "X-Archive-Orig-Last-Modified", but now we have a good search term, thus: https://gitlab.com/gnuwget/wget2/issues/205 So, the gnu wget seemingly can parse it, why woudn't a Windows wget? As a matter of fact I just tried this: https://eternallybored.org/misc/wget/ Version 1.9.4 as I am on XP: https://eternallybored.org/misc/wget/releases/old/wget-1.19.4-win32.zip And I got this: Hep! Now, the attentive reader will have noticed that the timestamp is not actually correct, the Wayback Machine sent: Tue, 02 Sep 2014 22:33:03 GMT Whilst the file timestamp I got is: 03/09/2014 00.33 But this is inherent to the way filesystem timestamp change depending on local time settings, the actual NTFS timestamp is UTC, i.e. roughly GMT, but it appears according to my local settings. jaclaz

Anything that: 1) is a good conductor (i.e. copper, aluminium, iron/steel etc,) 2) can be wrapped around the cable (i.e. metallic foil/tape) or into which the cable can be inserted into (metallic pipe) 3) is continuous and thus can (optionally) be grounded (on one end ONLY) will do nicely. jaclaz

Very likely it is (was) a non-canonical ACL : https://support.microsoft.com/en-us/help/320081/you-cannot-delete-a-file-or-a-folder-on-an-ntfs-file-system-volume What I would do (once everything is actually disabled/deleted/etc.) Copy the Far.exe to a FAT16/32 volume. Delete the Far.exe copy on the NTFS volume. Copy back from FAT volume to the original NTFS folder. Check again NTFS permissions. Alternatively, use SetACL: https://helgeklein.com/setacl/ jaclaz

Wait a minute, which OS is that? XP Home? (but I seem to remember that Home misses it on folders also ) In case: https://www.bleepingcomputer.com/forums/t/281059/how-to-add-security-tab-in-windows-xp-home/ Are you sure the file is actually a file (and not a link)? Anyway, try checking it with CACLS or XCACLS: https://ss64.com/nt/cacls.html https://ss64.com/nt/xcacls.html So, if I get it right, when Threatfire is running with the far.exe added to the exclusion list, you can run it once but not twice, and now with Threatfire disabled it cannot run even the first instance? Then it must be still connected to Threatfire. jaclaz

Hmmm. If you could post a link to the file, that would surely help. Free Download Manager used to have such an option, but I believe it is not there anymore in 5.x version, you might need an old version, try using the "lite" 3.9.7: https://www.freedownloadmanager.org/download.htm .Of course it may also depend on server side. jaclaz

Well, first thing you should check the permissions of the file (and of the directory where it is): http://www.ntfs.com/ntfs-permissions.htm You may need to take ownership. You are however "mixing" two different "features". One is NTFS permissions (that have been on NTFS since the dawn of time) and the other is UAC, User Account Control, which is the "new" thing since Vista). BUT it seems strange that it can run once and then no more. Is it not some feature of that "Threatfire" thingy? jaclaz

What do you mean? I.e. it started "suddenly" and "before" you had not that issue? Which kind of connection do you have? Loosely, anything up to the "delivery point" of a service (i.e. normally up to the cable box/receptacle inside your house) is property of the ISP and you cannot touch it. Changing the cable from the (ISP owned/connected) receptacle to your modem is doable, of course, but that won't help if there is RF injection before that point.. And I have never seen triaxial cable used for data transmission, they are used AFAIK in video trasmission in the aircraft industry *like*: https://www.picwire.com/cables/video-mates/ The only thing that you can do is - I believe - to have the cable replaced (by the ISP, and only if they accept to do it) and have it put into a shield, a copper pipe would do nicely but there are also specific products *like*: https://www.tech-etch.com/shield/install.html jaclaz

Yep , if you can call (keeping a straight face I mean ) running Windows 98 on a 4 Kb sectored 17 TB disk "practical" . jaclaz

Try again: bcdboot C:\Windows /l en-us /s k: /UEFI If you still have the error (and even if you haven't it), run a DIR command: DIR /S K:\Efi And/or: DIR K:\Efi\Microsoft\Boot Verify that a file K:\Efi\Microsoft\Boot\bootmgrfw.efi and a file K:\Efi\Microsoft\Boot\BCD actually exist. If they don't, try checking if bootmgfw.efi and bootmgr.efi exist here: C:\Windows\Boot\EFI\ If they do run: mkdir K:\EFI\Microsoft\Boot xcopy /s C:\Windows\Boot\EFI\*.* K:\EFI\Microsoft\Boot then try running again: bcdboot C:\Windows /l en-us /s k: /UEFI If you still have the error and you still boot to the grub rescue prompt, type in it: root (hd1,gpt1) [ENTER] chainloader /EFI/Microsoft/Boot/bootmgfw.efi [ENTER] boot [ENTER] the (hd1,gpt1) in the above means first gpt partition on first disk, if the EFI partition (the one you assigned the drive letter K; ) is not the first one, change accordingly. What happens? jaclaz

That is the issue. What you are asking is seemingly about wanting TWO "Program Files" folders, one on the HDD and one on the SSD, but there can be only one. Once upon a time programs (well most of them with the usual exceptions of - say - MS and Adobe) could be installed *anywhere* (i.e. not necessarily in "Program Files") and even had (easily) the possibility to tell them where to store their "work" files. Nowadays this can still usually be done but it is complex and a number will use as "Program Files" folder the location set in the Registry for it. If you want to have the actual files pertaining to "Program Files" residing on another disk you can (alternatively): 1) change the location in the Registry for "Program Files" (and also for "Program Files (x86)" to point to another volume OR 2) make in the C:\Program Files (or - IMHO better - the various programs folders inside it) a junction to another volume (softlink) folder Hard to say which one is a "better" solution, considering that you will also find (hopefully a few only) programs that will want to install to "C:\Progtam Files" anyway (hardcoded path in the installer) if I were you I would choose #2. A "better" solution (IMHO) is to actually manually install the programs to (say) D:\myPrograms leaving alone the "normal" C:\Program Files, this will allow you to obtain (more or less) what you asked for, i.e. two "Program Files" folders on two different volumes. Still I believe that YMMV, depending on the specific Program that may (or may not) allow that. jaclaz

The partition needs to exist AND it needs to be mounted to a drive letter. (Hint: normally EFIBOOT partitions are NOT assigned a drive letter automatically) If you don't know how to look at your partitions (Hint: Diskpart or Disk Manager) and you don't know how to assign a drive letter to a partition (Hint; Diskpart or Disk Manager) it will be a looong thread . Let alone if you need to create some space on the disk, and create/add a new EFIBOOT partition. It is of course doable, but if the main objection is "its too general and lowlevel" you won't get very far, in order to do (mildly) advanced things you need (mildly) advanced knowledge, or refrain from doing them or ask for assistance before doing them. I have no idea : 1) how was (EXACTLY) your "old" disk, OS, etc. setup before 2) how (EXACTLY) you partitoned and formatted the new disk 3) how (EXACTLY) you copied what (EXACTLY) 4) what (EXACTLY) is on your new disk 5) what (even if not exactly, approximately) is your level of familiarity with the Windows (and/or Linux) OS 6) etc. Is it so surprising that the advice is "general" (because of the lack of details) and "lowlevel" (since if you need ot repair a boot it is actually "lowlevel")? Anyway, see if an almost complete tutorial helps: http://woshub.com/how-to-repair-uefi-bootloader-in-windows-8/ If you don't have the EFIBOOT partition, how to create it may depend on whether you have space for it on the disk or if you need to resize another partition, generally the "right " set of instructions are here (as in theory a Windows 8+ installation also has a MSR 128 MB partition/volume: https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/configure-uefigpt-based-hard-drive-partitions https://systemscenter.ru/waik.en/html/79f51a90-a8e9-410d-bd76-af197b865a49.htm jaclaz

BCDBOOT: https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/bcdboot-command-line-options-techref-di jaclaz

Little green men have come a long way since when they were just stealing socks ... green men 2.0! jaclaz

No it isn't, should have been called BluetoothMonitor: https://www.nirsoft.net/utils/bluetooth_viewer.html jaclaz

Try following this: https://www.tenforums.com/drivers-hardware/22049-how-completely-remove-bluetooth-device-win-10-a.html https://www.tenforums.com/drivers-hardware/22049-how-completely-remove-bluetooth-device-win-10-a.html#post1540911 The mentioned tool seems like capable to unpair on-yhe-fly ALL Bluetooth devices: http://bluetoothinstaller.com/bluetooth-command-line-tools/ http://bluetoothinstaller.com/bluetooth-command-line-tools/btpair.html jaclaz

lawlietfox-67.0.4-1-win64-vc15-nopgo-O2 How queer. jaclaz

OT, I know, but it would IMHO suit a system with A: as systemdrive (no idea if it actually works post-XP): http://www.novell.com/coolsolutions/tools/14474.html jaclaz