Basically Windows is making a diary of every single folder/filenames you’ve visited in chronological order. Just learned about something called ShellBag while using NTlite to slipstream Windows. WTF!
Parents can run a scan with ShellBag Analyzer in their family computer and see what their teenager has been up to!
Everybody should first disable this feature by running this registry settings (or manually creating the DWORD entry and set it to 1) which you can download and execute below:
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell]
"BagMRU Size"=dword:00000001
Sometimes Windows recovery mode do not have the ‘Startup Repair’ option like this below
I don’t know under what condition it won’t show up (sometimes I plug the system drive to be repaired in a computer, it shows up, at least for Windows 2008 R2), but you can selection Command Prompt (always available) and go to X:\sources\recovery and run startrep.exe to launch the repairing tool.
I tried to use Putty to connect to my serial port test instrument (Agilent’s 33120A or E3600 series power supplies) and to my dismay it doesn’t respond to my commands.
I figured it might be newlines not being recognized properly. Checked the programming manuals and found that HP/Agilent accepts LF (‘\n’)as newline and optionally allowing a CR (‘\r’) before it (i.e. CR+LF like Windows).
I thought this configuration (Implicit LF in every CR) would work:
However it doesn’t! I had to dig through internet forums to find out that the ‘Terminal’ settings page controls what gets SPIT OUT TO THE TERMINAL SCREEN, not how your keystrokes are treated/sent! This page controls what your keystrokes mean:
and the convention for ENTER is Ctrl+M (also mentioned here):
https://ss64.com/bash/syntax-keyboard.html
So if you want ENTER/RETURN key to generate LF (instead of CR) with the official putty, you have to press Ctrl+J each time!
Putty sending CR (Ctrl+M) with ENTER key by default is also hinted by the default Telnet (only applies to telnet, not serial) setting in the Putty docs “Return key sends Telnet New Line instead of Ctrl+M”, which means outside Telnet, it the default behavior or ENTER/RETURN key is Ctrl+M (CR)!
Ironically even HyperTerminal came with the option to send out CR+LF on ENTER key! Luckily some kind soul (Grzegorz Niemirowski) compiled a mod (currently v0.74) which added the option and and posted it on Stack overflow:
Symantec Ghost has been my favorite tool since high school as the user interface is minimalistic (runs fast) yet intuitive. It pretty much has every single feature (use case) you can imagine organized in a sensible way (unlike the fucking linux man pages that drown you with 4 dozens of command switches not logically organized so you have to skim through the entire thing to find out what is relevant).
The software is well made in general so we can get a lot mileage out of old versions. I recently had to clone a drive over the network yet I don’t want to share the image file. My initial plan is to have the remote computer I plan to image the disk attached to it run as slave (in Master-Slave mode Peer-To_Peer over TCP mode), but there are a few hurdles:
The documentation didn’t say which port is used. I have to use TCPview to figure it out. It’s Port 6668.
Turns out slave mode does not support restoring from a image file located from the (puppet-)master. In other words, the when you connect to the slave session, the file dialog box of “From Image” only shows the files on the slave side! WTF!
It’s strange that you can clone a raw drive / partition from master session to slave session, but you cannot choose image file as a source in place of the source drive. I tried the command line before and no avail. After some web searching I realized that I’m not insane. It was the way Ghost is:
The rules inferred from this table means:
image files ALWAYS stay at the slave session
direct drive/partition copies is always master pushing data to slave.
slave drives are never cloned (read)
master cannot read its own files to find image files
master can only select remote (slave) image files
First of all, direct drive-to-drive copy are bidirectional. The above list is not entirely accurate, so I stroke through the conclusion derived from the incorrect assumptions above. Y:
The rules for image files do not make much sense to me. Just can’t come up with a good excuse for it. The session have full access to both storage from both sides, and ghost command line’s logic is to make image files fungible with direct drives/partitions. It doesn’t discourage accidental overwrites or prevent one side’s data from being siphoned. All they did is to tease the user by not allowing them to read files/images from the master computer where the user interaction is.
The first instinct is to restore the GHO image I want to push to the server onto a disk and do the direct clone. This is logically fungible with creating a VHD, mount it, restore the GHO image to the mounted drive, then use direct ‘virtual disk’-to-disk clone to restore the remote (slave) disk. Luckily, newer Ghost has tools to simplify these steps. We’ll need this 3 pieces of clues to figure it out:
Virtual machine disk image files such as VHD can be used as source or destination
There’s a command switch to mount virtual machine disk image files internally WITHIN the ghost session (no side effects: windows won’t see it. Won’t persist between ghost sessions)
GHO files are not directly mountable as a virtual disk even internally within ghost session
So the complicated process can be shorten to converting GHO to VHD and then internally mount the VHD as a direct drive through command switch launching Ghost. Use DEMO.gho as an example:
REM Convert DEMO.gho to DEMO.vhd
ghost -clone,mode=restore,src=DEMO.gho,dst=DEMO.vhd
REM Launch Ghost with DEMO.vhd internally mapped as a (direct) logical drive
ghost -ad=DEMO.vhd
I ran into some obscure error messages like “ABORT: 11030, Invalid destination drive” when trying to specify the full absolute path. So instead of fussing with the syntax that breaks the code, I added ghost to my Windows %PATH% environmental variable and run ghost directly at the folder where the files are. I suspect it can be fixed with /translate command switch to make sure the drive letter is not ambigious whether it’s local or remote, but that’s something for later if I have a project that require scripting this reliably.
My cliff notes here.
Run Ghost as slave mode
ghost -tcps
Do this at Ghost master computer
REM Convert DEMO.gho to DEMO.vhd
ghost -clone,mode=restore,src=DEMO.gho,dst=DEMO.vhd
REM Launch Ghost with DEMO.vhd internally mapped as a (direct) logical drive
ghost -ad=DEMO.vhd -tcpm:{IP address of the slave computer}
Remember to open port 6668 at the Ghost slave computer.
Appendix
Technically, it’s possible to restore from an image file located AT THE SLAVE side, but it’d be a stupid idea. Initially I thought Ghost would be smart enough to directly use the image file locally on the slave session to clone the drive locally. However, given the speed and my observation with TCPview, this is not the case. It’s doing the stupid thing of crawling the contents of image file from the slave machine in chunks and send it back to the slave!
Deltacopy is a GUI wrapper around rsync, a feature-packed tool to copy files locally AND remotely, AND differentially (automatically figure out the parts that are different and resend. Excellent for repair) through hash comparisons. For non-programmers, hash is a unique ID computed for a chunk of data that are expected to change wildly even at the slightest data/file change/corruption).
Deltacopy is very useful if you just want to do the basic stuff and not know the rsync syntax and switch combinations off the top of your head. It also provides a windows port of rsync based on Cygwin (a tiny Linux runtime environment for windows). This is the only free alternative to cwRsync, a paid Windows port of rsync.
rsync is a Swiss Army Knife that can also work from one local path to another. Deltacopy is intended for remote file transfer.
Deltacopy server is basically this:
rsync --daemon
However in Windows, since it’s cygwin, it’s looking for linux’s /etc/rsyncd.conf by default if you do not specify the config file through --config switch.
Deltacopy client basically help you generate the command to transfer files. Most of the features are done through right-click (context) menu, not toolbar or pull-down menus, which might confuse some people. You set up your tasks as Profile, which can be scheduled (the bottom panel) or executed immediately by right clicking on the profile:
Run is pushing file to the server, Restore is pulling files from the server. Run Now and Restore are for executing the command (aka task) immediately. You can peek into what it generated by right-clicking on the profile and choose “Display Run/Restore Command”. First time users might not be able to find it since the only place to access it is through context menus.
There are some tricky parts (gotchas) for specifying the files/folders to copy. First of all, even though you use Add Folder/Add Files button for entries
Basically you can make a (source, destination) pair by modifying the selection and target path. It’s just passed onto rsync command verbatim. The target path is relative to the virtual directory set on he server (see Deltacopy Server’s directory)
The destination path which is endowed with the branch folder name (one-level). In other words, if your source is C:/foo/bar, Deltacopy by default set the destination to /bar instead of /. This is probably to avoid the temptation of lumping all contents in the same remote destination root. If you just want to simply lay the files at the root virtual folder at the destination (my most common use case), you’ll have to edit and clear out the (relative) destination path.
As for the source, the author of rsync chose to do it the logical (more conservative) way but not intuitive way: by default it reconstruct the source folder’s FULL path structure at the destination! For example if you intend to copy everything under C:\foo over, the destination will create {destination root}\foo in the process and put everything under it instead of directly at {destination root}. The design choice was supposed to prevent accidental overwrites as multiple source subfolders try to write over each other with the same names at the destination.
Luckily, there’s a way around it! See man pages for -R –relative: Put a dot (.) at the place where the relative path starts! For example, the source is C:\foo\bar\baz and you do not want /foo to be created at the destination and want it to start with /bar instead. You should enter C:\foo\.\bar\baz as source. Everything the left of the dot (refers to self-folder) are stripped from the destination path structure.
ACL support for Windows sucks because rsync lives on cygwin, which has POSIX (unix/linux) type of permissions/ACL.
In my opinion, the best way to go about it is to not transfer ACLs from the source and follow the preexisting ACLs at the destination. I’d also leave the groups and owners alone (inherit at destination) as well I might not be on the same active directory (or workgroup user management) as the destination computer so accounts with the same name might not be actually the same accounts.
--no-p --no-g --no-o
–no-{command} is the complement prefix that does the opposite of the -{command}, so the above means skipping -p (perms/permissions), -g (group), -o (owner) and make sure it has full permissions for everybody.
Sometimes a remote path can be mistaken as a relative local path with the hostname/IP address as the folder name if there’s no username. Start it with rsync:// as the URL scheme and the syntax is like ftp:// as far as username is concerned.
Deltacopy protects the source and destination paths with double quotes (“). It’s a good practice that we should do it even with direct rsync calls.
