I've bunch of symlinks that point to the %temp% directory that's on my RAMDISK, sometimes, I've to move the %TEMP% directory off RAMDisk and onto my SSD for whatever reasons. How do I make all Symlinks follow the new %TEMP% directory in SSD and vice versa?
PS: The files here aren't important, I don't care if directory or it's content get deleted in process, it's mostly temp/cache files of programs I use which write small files constantly.
Related
In WSL2, is it possible to access the Windows Recycling Bin? Say for example you move file.txt into the recycling bin in the Windows GUI, could you move to the directory that file.txt is contained in on the WSL terminal? How could this be done?
Officially, no. A special implementation of IShellFolder in shell32 handles the recycle bin when files are moved/deleted in the shell namespace.
Unofficially, each drive contains a hidden $Recycle.Bin folder (Recycler before Vista). Each user has a directory inside there named after their SID where their deleted files are stored.
The deleted files do not retain their original filenames, only their extension. Before Vista, a file named INFO2 stored this information. These days $I... stores the information for the original files renamed to $R...
Look at forensics tools like Rifiuti2 if you need to understand the internal format so you can extract the original name...
so I have external hdd hooked up with 2015 early mac book pro, usually when I want to access it I just type in cd /volumes/MAC -ls, will show all the files and folder in it.
Due to not ejecting properly, now I can't access that folder. Rather I see a new folder with same name like - cd /Volumes/MAC\ 1/. And I see all my files and folder in this folder.
Can anybody shed some light on it.
Thanks
This is probably happening due to a quirk of the way unix (and hence macOS) mounts volumes. They don't actually mount as folders, instead they mount over top of existing folders. Thus, when macOS detects that you've plugged in an external drive, it normally does something like this:
Figure out what the volume's "name" is
Create an empty folder named /Volumes/[volumename]
Mount the volume on that folder
When you unmount the volume, it does the reverse: it does the actual unmount, then deletes the folder it was mounted on. But if something goes wrong, and that folder doesn't get deleted, the leftover folder can cause this to happen when you attach the drive:
Figure out what the volume's "name" is
Try to create an empty folder named /Volumes/[volumename]... Oops, that already exists, better try something else.
Try to create an empty folder named /Volumes/[volumename 1]... Whew, that worked; we'll use that
Mount the volume on the /Volumes/[volumename 1] folder
Fortunately, the solution is pretty simple: check the leftover /volumes/MAC folder (or whatever it is using that name), make sure it doesn't contain anything important, delete it (or at least rename it), then cleanly unmount & remount your volume -- with the correct name available in /Volumes, it should mount without the " 1" suffix.
The termimal escape the space, thus you get MAC\ 1 for a folder named MAC 1.
Now as MAC was mounted, unmounted properly, then re-mounted, it was renamed from MAC to MAC 1
I have a huge batch of flash drives that I need to move files onto. I'd also love to rename the drives (they're all called NO NAME by default). I'd love to plug two drives in, run a terminal script on the computer to accomplish all of that (most importantly the file moving). Then remove the drives, put the next two in, run it again, etc. until I'm done. All of the drives are identically named.
Is batch executing like this possible, and does anyone know how to go about doing it?
I figured it out. Put each one in and run this command to rename the drive and then move the files into it:
diskutil rename /Volumes/OLDNAME "NEWNAME" && cp -r ~/Desktop/sourceFolder/. /Volumes/NEWNAME
I have a directory containing source code, which I compile to produce object files. I want to quickly apply a patch and rebuild in such a way that I have simultaneous access to both the old and new object files. One way to do that is:
cd old && make
xcopy old new
cd new && apply diff && make
However, the copy takes about 10 minutes, even on the same drive. If I could make new be a copy-on-write version of old that would be much faster. Can Windows 7 NTFS create copy-on-write directories? Can these directories be expanded to copy-on-write subdirectories when the outer directory is modified?
If you create a VHD and mount that in that directory, you can independently configure VSS on that volume and therefore on that directory.
I am using RSync to copy tar balls to an external hard drive on a Windows XP machine.
My files are tar.gz files (perms 600) in a directory (perms 711).
However, when I do a dry-run, only the folders are returned, the files are ignored.
I use RSync a lot, so I presume there is no issue with my installation.
I have tried changing permissions of the files but this makes no difference
The owner of the files is root, which is also the user which the script logs in as
I am not using Rsync's CVS option
The command I am using is:
rsync^
-azvr^
--stats^
--progress^
-e 'ssh -p 222' root#servername:/home/directory/ ./
Is there something I am missing to get my files copied over?
I can think of only a single possibility: My experience with rsync is that it creates the directory structure before copying files in. Rsync may be terminating prematurely, but after this directory step has been completed.
Update0
You mentioned that you were running dry run. Rsync by default only shows the directory names when the directory and all its contents are not present on the receiver.
After a lot of experimentation, I'm only able to reproduce the behaviour you describe if the directories on the source have later modification dates than on the receiver. In this instance, the modification times are adjusted on the receiver.
I had this problem too, and it turns out that backing up to a windows drive from linux doesn't seem to copy the temp files in place, after they are transferred over.
Try adding the --inplace flag, when rsyncing to windows drives.