I have a Linux subsystem installed on my Windows machine. I've transferred a tar.gz file I want to access by finding the location of my subsystem and dragging the files over. But when I run the command:
tar -zxvf file_name.tar.gz
I get the error:
tar (child): vmd-1.9.4a51.bin.LINUXAMD64-CUDA102-OptiX650-OSPRay185.opengl.tar.gz: Cannot open: Permission denied
tar (child): Error is not recoverable: exiting now
tar: Child returned status 2
tar: Error is not recoverable: exiting now
I assume permission being denied is to do with having transferred from Windows since I couldn't access directories I created through Windows either. So, is there something I need to change to gain access to these files?
(PS. I know there are other way of getting tar.gz files other than transferring from Windows, but I'll need to do this for other folders too, I only included the filetype in case it was relevant .)
EDIT: You shouldn't attempt to drag files over. See answer below.
For starters, this belongs on Super User since it doesn't deal directly with a programming question. But since you've already provide an answer here that may be slightly dangerous (and even in your question), I didn't want to leave this unanswered for other people to find inadvertently.
If you used the first method in that link, you are using a WSL1 instance, not WSL2. Only WSL1 made the filesystem available in that way. And it's a really, really bad idea:
There is one hard-and-fast rule when it comes to WSL on Windows:
DO NOT, under ANY circumstances, access, create, and/or modify Linux files inside of your %LOCALAPPDATA% folder using Windows apps, tools, scripts, consoles, etc.
Opening files using some Windows tools may read-lock the opened files and/or folders, preventing updates to file contents and/or metadata, essentially resulting in corrupted files/folders.
I'm guessing you probably went through the install process for WSL2, but you installed your distribution before setting wsl --set-default-version 2 or something like that.
As you can see in the Microsoft link above, there's now a safe method for transferring and editing files between Windows and WSL - the \\wsl$\ tmpfs mounts. Note that as a tmpfs mount stored in memory, it's really more for transferring files over. They will disappear when you reboot or shutdown WSL.
But even if you'd used the second method in that article (/mnt/c), you probably would have run into permissions issues. If you do, the solution should be to remount the C: drive with your uid/gid as I describe here.
Related
There is an application on remote machine with Linux OS(Fedora), writing to the log file when certain events occur. Some time ago I changed format of the message being written to the log file. But recently it turned out that for some reason in some seldom cases log files with old format messages appear there. I know for sure that none part of my code can write such strings. Also there is no instance of the old application running. Does anyone have some ideas why it can happen? It's not possible to check which process writes those files because anything like auditctl is not installed there, and neither package manager or yum to get it or install. Application is written in C language.
you can use fuser command to find out all the processes that are using that file
`fuser file.log`
I have a legacy VB6 system which is installed in C:/Program Files/IronDuke
In the past it has written some files into this directory. I understand that these files are hidden away if the application is installed under Vista or a later OS, but not if they were written under XP or earlier OS.
How can I retrieve a copy of these 'hidden' files when written under Vista or Windows 7 or 8?
You are looking at a feature called UAC Virtualization, this blog posting gives a pretty good rundown on what is happening and where the files are located.
From above article:
For example, if an application attempts to write to C:\Program Files\Contoso\Settings.ini, and the user does not have permissions to write to that directory (the Program Files), the write operation will be redirected to C:\Users\Username\AppData\Local\VirtualStore\Program Files\Contoso\settings.ini. If an application attempts to write to HKEY_LOCAL_MACHINE\Software\Contoso\ in the registry, it will automatically be redirected to HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\Software\Contoso or HKEY_USERS\UserSID_Classes\VirtualStore\Machine\Software\Contoso.
so in your case if you are trying to find the files you need to look in:
C:\Users\Username\AppData\Local\VirtualStore\Program Files\IronDuke\
You cannot write to Program Files under Windows 7 / 8 - system security prevents programs running as regular users from doing so. One option for you is to write these files to the user's profile folder (you'll have to update the VB6 program for this, although the changes should be pretty small if the program is otherwise well-written). This would be your best option since the updated code would work well in the future without more changes.
You amy be able to get the program running using Compatibility Mode but I doubt it - on my Windows 8 system I don't even get 'Windows XP' as a compatibility option anymore. All other options will likely enforce security.
You can try running your program as administrator but I'd only do this if you don't have the source to make the changes - it's poor practice to run programs with all privileges since it opens up the system for attacks.
Whenever I open one of the Quantum Grid demos in Delphi XE Pro (on Windows 7 32-bit), the following error is displayed for every table (I think) in the project:
error message http://www.tranglos.com/img/qgerror.png
The message is:
Network initialization failed.
File or directory does not exist.
File: C:\PDOXUSRS.NET
Permission denied.
Directory: C:\.
I understand permission issues writing to c:\, but the result is that while I can build and run the demo projects, no data is displayed, which makes the demos rather useless. And what kind of database writes its configuration to c:\ directory in the 21st century anyway? :) (Yes, I know very little about Paradox databases, but I won't ever be using one either. I just want to learn how to use the grid.)
Using BDE Administrator I've tried changing the Paradox "NET DIR" value to a folder with write permissions on the C drive. Result: now the database tables cannot find their data:
Path not found.
File: C:..\..\Data\GENRES.DB.
...and the unhelpfully truncated path gives no indication where the files are expected to be.
Is there a way to work around the problem so that the demos can load their sample data correctly?
Did you install the BDE correctly? It should use the DBDEMOS files. Do you see such an alias in the BDE administration utility? Can you open that database in one of the Delphi demos?
The BDE is not a XXI century database, it was developed twenty years ago and never upgraded lately. It's an obsolete tecnology, but because it comes still with every release of Delphi with a known database it is still often used in demos because nothing new has to be installed.
Anyway that file is not its configuration file. It's a sharing lock file to allow more than one user to use the database concurrently. Because it is a file based database without a central server, it has to use such kind of shared files. Usually its position is changed to a network share, but it defaults to C:\ for historical reasons.
Anyway it's not only the BDE still attempting to write in the prong directories. I still see a full bunch of applications attempting to write to C:\ (especially logs) or other read-only positions.
Using BDE Admin to change the location for PDOXUSRS.NET helped, but it wasn't sufficient. DevExpress did the right thing in specifying a relative folder for the data location, and the relative folder seems perfectly allright, but for some reason the DB can't find it.
Solution: under the \Demos\ folder find all the *.dfm files that contain the string
..\..\Data
and replace that string with the absolute path to the demos folder. That done, all the demos open correctly.
I know this message from our own applications. It has to do with security measures introduced with Windows Vista. The operating system trying to protect critical files denies access to them. There is a method how to bypass this mechanism without compromising security. Try to run your application in compatibility mode. When application is running in compatibility mode, read / write operations from / to system folders are redirected to "safe" directories located in C:\Users[Current User]\AppData\Local\VirtualStore.
More info on http://www.windowsecurity.com/articles/Protecting-System-Files-UAC-Virtualization-Part1.html.
I have some automated test (using CUnit) which require a "disk-image"-file (raw copy of a disk) to be "mounted" in windows and explored. I have previously used a tool/library called "FileDisk-17" , but this doesn't seem to work on my Windows 7 (64bit).
Update
I should point out, that changing the image-format (to say VHD) is not at option.
Any suggestions as to other (perhaps better supported) tools or libraries for mouting the file? The project is coded in ANSI C and compiled using MinGW.
Best regards!
Søren
Edit: Searching Bing for +filedisk 64 brings up a 64bit build of FileDisk, the utility you refer to:
http://www.winimage.com/misc/filedisk64.htm
And FileDisk-15 signed for 64bit here:
http://www.acc.umu.se/~bosse/
I can't vouch for it as I have never used it and am not familiar with the author.
Alternatively:
If you have a VHD, you can mount that in windows easily:
http://technet.microsoft.com/en-us/library/cc708295(WS.10).aspx
See also:
http://www.petri.co.il/mounting-vhd-files-with-vhdmount.htm
Since you have a raw DD image not a VHD, you will need to convert it first:
http://www.bebits.com/app/4554
Or qemu-img.exe can also do this:
qemu-img.exe convert -f raw rawdisk.img -O vpc rawdisk.vhd
Alternatively, you can create an empty VHD, and use DD to copy the raw image to the VHD, by opening the VHD as a raw device.
I faced this problem recently and found ImDisk to be an extremely nice solution:
Free, with source available and a very flexible open source license
Trivial setup (I have seen filedisk64 (in the accepted answer) described as having a "technical" setup)
Straightforward GUI and command-line access
Worked on Windows 7 64-bit
Seems to happily mount any kind of filesystem recognised by Windows (in my case, FAT16)
Works with files containing
Raw partitions
Entire raw disks (i.e. including the MBR and one or more partitions; which partition to mount can be selected)
VHD files (which it turns out are just raw partitions or disks with a 512-byte footer appended!)
Also can create RAM drives -- either initially empty or based on an existing disk image! (Very neat I must say!)
I did encounter minor issues trying to unmount drives. I was unable to unmount a drive from the GUI right-click context menu as the drive appeared to be "in use" by the explorer.exe process. Closing the Explorer window and using imdisk -d -m X: also didn't work; however imdisk -D -m X: (-D "forces" an unmount, whatever that means) did. This worked even if the drive was visible in an open Explorer window, without appearing to create any problems. However even after the drive appeared to have fully unmounted, an imdisk -l to list all available devices would still report that \Device\ImDisk0 exists, and if you remount the drive later, both that and \Device\ImDisk1 will appear in the output of imdisk -l (and so on with more unmount/remount cycles). This didn't create any problems with actually using the mounted drive when I tried a few unmount/remount cycles, though it theoretically might if you perform this many times between reboots.
ImDisk was invaluable for transferring the contents of a 1.5Gb disk drive with one FAT16 DOS partition from an ancient 486 machine.
I am writing a terminal-based application, but I want the user to be able to edit certain text data in a separate editor. For example, if the user chooses to edit the list of current usernames, the list should open as a text file in the user's favorite editor (vim, gedit, etc.). This will probably be an environment variable such as $MYAPPEDITOR. This is similar to the way commit messages work in svn.
Is the best way to do this to create a temporary file in /tmp, and read it in when the editor process is terminated? Or is there a better way to approach this problem?
There's already a $EDITOR variable, which is extremely standard and I have seen it working on a wide variety of unixes. Also, vi is always an option on any flavor of unix.
Debian has a sensible-editor command that invokes $EDITOR if it can, or falls back to some standard ones otherwise. Freedesktop.org has an xdg-open command that will detect which desktop environment is running and open the file with the associated application. As far as I know, sensible-editor doesn't exist on other distributions, and of course xdg-open will fail in a text-only environment, but it couldn't hurt to try as many options as possible, if you think it's important that a desktop user can see their happy shiny gedit or kate instead of scary old vi or nano. ;)
The way crontab and sudoedit work is also by making a file in /tmp. git puts it under .git, and svn actually puts it in the current directory (not /tmp).
The way svn and mercurial do it is by making a file in /tmp.
BTW, you don't need a MYAPPEDITOR, on nix there's EDITOR already present.
Since you mention svn in your post, why not just follow the same methodology? svn opens a file with a particular name with whatever $EDITOR (or $SVN_EDITOR) contains - this might actually require some work on your part; determining the parameters to each supported editor. In either case, you have the name of the file that was saved (or the error code of the application if something failed) and you can just use that.