I installed a Linux Ubuntu subsystem onto my Windows 10.
Ubuntu itself works fine and I can access all the Windows files without a problem.
But somehow I can't access the files the other way around, meaning I can't find the lxss folder where all the files from Ubuntu are stored.
I already made all folders visible, even the system ones. There just isn't a lxss folder.
In fact, there is not a single lxss folder on the whole drive.
Ubuntu must save the files somewhere, I just don't know where...
Related
I installed Ubuntu terminal as now Windows 10 supports it. I built the Nuttx RTOS using the terminal but in Ubuntu I cannot access USB devices except for a pen drive.
How can I flash the bin file to stm32f4developer?
You can use windows tools. All of the files in the Ubuntu "sandbox" can be access by Windows tools running outside of that sandbox. In the top-level NuttX README:
Accessing Ubuntu Files From Windows
In Ubuntu Userspace for Windows, the Ubuntu file system root directory is
at:
%localappdata%\lxss\rootfs
Or
C:\Users\Username\AppData\Local\lxss\rootfs
However, I am unable to see my files under the rootfs\home directory.
After some looking around, I find the home directory
%localappdata%\lxss\home.
With that trick access to the /home directory, you should actually be
able to use Windows tools outside of the Ubuntu sandbox with versions of
NuttX built within the sandbox using that path.
As user6711188 explained you can access your home at %localappdata%\lxss\home or you can copy the nuttx.bin directly to Windows side:
$ cp nuttx.bin /mnt/c/ProgramData/
You will need to configure Windows Explorer to show Hidden files, this way you could see the nuttx.bin at C:\ProgramData
More info: https://acassis.wordpress.com/2018/01/10/how-to-build-nuttx-on-windows-10/
Problem and Hypothesis
It's a pretty simple problem, I just can't find the Lxss folder in LocalAppData which is suppose to store files from the Bash on Ubuntu on Windows.
I only see one of two possibilities for why this is. Either Windows moved the Lxss folder in an update for Bash on Ubuntu on Windows, or it is an error specific to my system that has caused Windows not to create the Lxss folder. I don't think this is the possibility though because it is a fresh install of windows.
Steps I have tried:
Unhiding files and folders in windows
Shutting down Bash on Ubuntu on Windows and refreshing my LocalAppData
Restarting Windows and checking my LocalAppData
Screenshots of LocalAppData:
I can add more information if needed.
It was actually moved in the latest release to :
C:\Users\%USERNAME%\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState\rootfs\
See this blog post from WLS git repo
You have to uncheck "Hide protected operating system files (recommended)" in the folder options window.
The selected solution is old and valid for Ubuntu only.
For Opensuse leap-15.1 users this is different:
C:\Users\"yourusername"\AppData\Local\Packages\46932SUSE.openSUSE-Leap-15-1_022rs5jcyhyac\LocalState\rootfs
The numbers will differ from version to version and may change in the future.
The trick is to look for something related to Linux in C:\Users\"yourusername">\AppData\Local\Packages\"xxxxx"\LocalState\root\fs
where
"yourusername" is your Windows 10 user login
"xxxxx" is a custom name related to the Linux distribution installed
In the latest version of Windows Fall Creator Update, I found it in C:\Users\%USERNAME%\AppData\Local\lxss\
I typically use the atom editor for any coding work and have folders on my computer with the code. After doing some updates on my Mac OS computer, some ruby gems stopped worked, rvm no longer responded and homebrew gave me a ton of trouble. I want to prevent this from happening again and figured I'd use Vagrant instead. I like it so far and it works fine, however I want to use my Atom editor nevertheless.
Normally I work on projects using gulp or grunt and they compile the files whenever any changes are made. While I have managed to connect to Vagrant with FileZilla, I have no idea how to connect atom to it. All I need is to edit the files in the Vagrant VM, as I would if they were stored in regular directories on my Mac. Any idea how to solve this?
you can certainly use your current workflow but you do not necessarily need to connect to your vm using Filezilla or another protocol.
The best is to look at Synced Folders and synchronized your project directory. By default vagrant synchronized your current directory (where the Vagrantfile is store) to the /vagrant directory in the vm. so if you can place your project directory within the same folder, they will be automatically synchronized.
If Atom (I am not user of this editor) have a special folder where you store your project files, you can add this folder as synchronized folder. Add the following to your Vagrantfile
config.vm.synced_folder "/Users/fhenri/project/tac.local", "/project"
In my case this synchronized my host (mac os) folder /Users/fhenri/project/tac.local to the vm folder /project so whenever I make a change in this folder, I can see the exact same change from the vm.
If you use ruby and gems, it might be good to install the gem locally (within your project structure that you can share between the host and the guest) so they are automatically reflected in the 2 environments when you make a change.
When you're using gulpor grunt you would launch them from the vm, working on a synchronized folder and all the changes you will make from the mac os host would automatically be picked up on the vm. I remember when working with default Virtual box sharing folder, automatically is not flash light, you should allow a few seconds delay but still it is working.
If performance is becoming an issue, you can look at nfs synchronization type by making the change
config.vm.synced_folder "/Users/fhenri/project/tac.local", "/project", type: "nfs"
It should improve a bit
I've recently set up an Ubuntu 12.04 LTS machine that I am using a local media server and web server for my projects.
My sites are run from ~/public_html on Ubuntu. That folder was then mapped to my Windows 8 machine. Previously I was using XAMPP, so I copied the contents of the htdocs/ folder to ~/public_html, this includes all the svn folders.
All sites are operating normally and are accessed via 192.168.1.10/SITE_NAME
Using NetBeans 7.2, the files are directly edited from the Windows machine. When the changes are committed using Tortoise SVN, the following error is reported:
Error: Commit failed (details follow):
Error: Unable to make name in 'V:\SITE_NAME.svn\tmp'
This was after creating a new text document in the root directory of the site from the Windows machine.
Any help would be greatly appreciated as I can't figure this out since I have full privileges on the folder.
Never use TortoiseSVN Working Copies on non-local drives
Check owner and permissions for files and folders in your WC
Change workflow and use post-commit hooks (server- or TSVN-side) to deploy code to site
Additional reading
I have two Macs, and a shared folder on a third Windows computer. If I do something like this:
Copy an executable console application (not a .app file - a single file which is executable) from Mac 1 to Windows machine
Zip executable on Windows machine
Copy new zip file to Mac 2 and unzip
The file that comes out of the zip file is still executable. How is the "executable-ness" nature of that file preserved, given that windows permissions system is totally different and doesn't really have the concept of executable files?
OSX Apps are folders, not files. When copying folders to a file system, that doesn't have executable bit representation, OSX creates hidden files for the missing attributes. Zipping the App is zipping a folder, including its hidden subfolders. On copy back, OSX will recreate the missing properties from the hidden files.
These hidden folders are called ._.OriginalName
EDIT
After quite extensive discussion in the comments sections, here is a bit of info about simple executable files (execute permission set) as opposed to *.app folders (native OSX applications)
Ofcourse OSX honours the executable permissions, (set and unset)
Copying a file to a file system, that does not have a concept of an executable permission (most prominently FAT formated USB sticks), then copying it back after a rename on another OS leaves OSX with the dilemma of whether to see the file as executable or not - the ._.OriginalName metadata store is decoupled from the file by the rename
OSX solves this dilemma by setting the permissions to 700 or 777, thus making every file executable