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...
Related
On a Win10 laptop, I have an application that writes data files to the C: root directory (DL900WIN, which is a home alarm security GUI). The PC Magazine utility FileSnoop v1.1.0.0 can see it and confirms the name, size, file/date and attribute "A". The filenames is "201207backup-DL900.DL1"
The Win10 File Explorer cannot see this file, even with "Hidden items" checked.
The Win10 CL dir does not show this file, with or without the /ah option.
The Win10 WSLinux does not show this file, even with the -a option.
If DL900WIN writes the file to a folder instead of C: root directory, then it is visible as a normal file should be. I can operate this way, but now I cannot delete the files in the C: root directory, so I'd like to learn.
What file system mechanism exists to hide a file in the root directory so that only FileSnoop (and DL900WIN) can see it? How can I access such a file with normal OS tools?
I'm working a programming project from school and decided to give Bash for windows a try. I downloaded the skeleton files for the project and pasted them inside the folder where my bash home folder should be. When I open the terminal and go inside the folder it shows as if there was nothing there even though I'm at the right folder. How can I get the files to be displayed?
EDIT: By now, there is actually a supported way to access these files. You have to use the \\wsl$\Legacy "network" share. For example, you could access your WSL home folder in Windows using \\wsl$\Legacy\home\<username>. Still, you should not directly access the lxss directory.
You are not supposed to touch the LXSS folder ever. The files there are use special attributes which are not understood by normal Windows applications to provide the features of a full Linux file system which NTFS on its own can't provide.
There is one hard-and-fast rule when it comes to Bash on Windows:
DO NOT, under ANY circumstances, create and/or modify Linux files
using Windows apps, tools, scripts, consoles, etc. Creating/changing
Linux files from Windows will likely result in data corruption and/or
damage your Linux environment requiring you to uninstall & reinstall
your distro! Note: Your “Linux files” are any of the files and folders
under %localappdata%\lxss – which is where the Linux filesystem –
distro and your own files – are stored on your drive
If you want to copy a file into a WSL directory which is not under /mnt, then use WSL to copy the file, i.e. use cp /mnt/c/original/folder/of/the/file.txt ~/ for example.
A more advanced alternative is starting a local SSH server in WSL and using Win-SSHFS to mount the WSL root as a drive in Windows. This way, file access will go through WSL.
Its unclear what you're asking in your question. What did you paste? Whole files? Text? Where did you paste it? Did you do the pasting into the bash window? If so was it inside a text file or did you just paste to the prompt? I'm going to assume that you pasted files to the directory that you believe that your bash home opens in i.e ~/. You may not be pasting the files into the correct directory because the default directory for bash on windows is not where you would assume it to be. you should be able to reach your desktop by typing cd /mnt/c/Users/yourUserNameHere/Desktop
The following Python script:
import os
print os.listdir('D:\images')
is outputing the names of all the folders in the D:\image directory, but it is also showing desktop.ini in the same folder, while there is no such file in the image directory.
Its also not a hidden item, I am sure of that.
Why is it then showing it as a content?
desktop.ini is a protected system file, and Windows tends to hide it.
You can verify by going to D:\images in a terminal and running dir /A.
See this answer as well.
You can use os.walk() if you want more control, it will give you directories and files separately. You can also use os.path.isdir() to find out if an entry you get is a directory.
I used os.path.isdir(path) to check whether the item returned by os.listdir() is a directory or not
This way,desktop.ini didn't meet the criteria of being a directory and my program scanned all the folders.
In Windows Explorer, when you open a ZIP file and double-click a file, say a JPEG file (.jpg), Windows extracts the JPEG file to a temporary folder, and passes the temporary file name to the associated program as the one and only argument, such as "C:\Users\jprice\AppData\Local\Temp\Temp1_<>.zip\<>.jpg"
I noticed that some applications, like the Windows Photo Viewer in Windows 7 know what ZIP file the temporary file came from. You can click next and previous and get the next/previous files from the ZIP file (as you do, they are also extracted to temporary files).
I've googled and prowled through system.io.packaging, but I can't figure out how to get the path of the original ZIP file (the file name is part of the temporary file path).
It's not done with the shell-->open command, Windows Photo Viewer only gets the temporary file name as far as I can tell.
The Photo Viewer command line is
%SystemRoot%\System32\rundll32.exe "%ProgramFiles%\Windows Photo Viewer\PhotoViewer.dll", ImageView_Fullscreen %1
Which doesn't help. I did use ProcessMon to watch Photo Viewer and saw it read the .zip file (probably using zipfldr.dll) but could not discover how it knew where the original zip file was.
When I try it, I notice that WinZip initializes the spawned process's current working directory to the folder that the .zip resides in. If you can extract the .zip filename from the temp file path (and older OS versions did not do that), then you can reconstruct the original .zip file path.
I was looking for a way to create hard links under Windows and I found this page: http://technet.microsoft.com/en-us/library/cc788097.aspx
To try it out, I created a file (1.txt) on the root of my C: drive with 100 lines of the following content:
C:\1.txt (2.598 bytes):
test test test test test
Then I open the command prompt and typed:
fsutil hardlink create C:\2.txt C:\1.txt
Success, 2.txt was created but when I go to see it's size it has exactly 2.598 bytes and also noticed some strange behaviours (as far as my understanding of hard links goes):
If I delete 2.txt (the hard linked file) 1.txt is not deleted, and vice-versa.
If I open 2.txt after I delete 1.txt (the original file) the content is still the same.
How does the fsutil hardlink create command differs from the copy command? And how can I create a true hard link under Windows?
I'm using Windows XP SP 3, and my file system is NTFS.
That's exactly the behavior that supposed to happen. Are you sure you understand how hard links work? Hard links are really just multiple entries in the file system that refer to the exact same file. If you create a hard link to a file and modify one of the instances of the file, the other file will show up with your changes because they both refer to the same blocks of data on disk.
When you delete one of the hard links, you're really just deleting one of the file system entries referring to that file. The file doesn't get deleted until you delete all of its hard links (including the original one). After you delete 1.txt, 2.txt still exists and refers to the same file that was originally there, only now there is only a single file system entry referring to that file (namely, 2.txt). 2.txt is that file.
How does the fsutil hardlink create
command differs from the copy command?
And how can I create a true hard link
under Windows?
After creating the hardlinked file, try editing either. You will discover that the changes are reflected in both files.
Try creating a hard-link of a very large file (say a video or disk-image). Notice that the available space on the disk has not changed (or not changed by more than a few bytes, if additional metadata had to be written to disk to reflect the new dir entry).
That is a true hard link. In UNIX (I'm not familiar with the Windows variant) a file is just a set of data on the disk (simplistically). It's the directory entry itself that gives that file a name.
When you have two directory entries pointing at the same underlying file, deleting one of them does not delete the file unless it's the last directory entry attached to it (and the file is not still open by a process, but that's a different matter).