When I try to save a file to disc within a project directory, I get this error:
java.io.IOException: W:\\[projectname]\\.idea not found
Some research tells me, the (network) location is not writable.
I'm trying to write this file from phpstorm in windows 8.
The drive (W:) is a network drive to a linux machine.
The directory I try to write to is chowned to the same user and group as I connect with in windows.
This is a result of ls -alh:
drwxrwxrwx 2 correct-user correct-user
On Linux and other Unix-like operating systems files starting with a . are considered 'hidden files' by default. As such, when the Windows-based program creates it, it suddenly doesn't see it anymore right after since it's hidden, even though the creation was successful. You can fix this in your Samba config by adding the following line to the share configuration:
hide dot files = no
In my samba settings I added a veto files parameter. Removing this parameter allows me to write dot files again.
Samba describes this setting as follows:
This is a list of files and directories that are neither visible nor accessible
Related
I'm running out of space on my C: drive, a 256GB SSD.
I started looking for a way to move the files in "C:\Program Files" and "C:\Program Files (x86)" to another disk. After googling (forever), I decided to write my own Python program that would copy the files from those directories to the destination drive and leave symlinks at the original locations. Since the files won't technically be moving, Windows should not care.
After testing, I began trying to actually move files from "C:\Program Files (x86)". I moved a couple of subdirectories to the roomier drive and nothing seemed amiss. Even WinMerge said the moved directories were identical to their originals, which should mean the symlinks are functional.
Precautions:
The Python program is run under my account from cmd.exe "as administrator" to avoid privilege errors.
The computer has been placed in Safe Mode to avoid problems trying to move programs that might be running.
My user account has Administrator privileges.
Controlled folder access is OFF in Settings/Virus & threat protection.
In spite of these precautions, when attempting to move another directory from (x86), Calibre2, I am receiving 10 errors similar to the following:
Traceback (most recent call last):
File "C:\Users\...\symmer.py", line 254, in _mv
os.remove(ps)
PermissionError: [WinError 5] Access is denied: 'C:\\Program Files (x86)\\Calibre2\\app\\bin\\api-ms-win-core-console-l1-1-0.dll'
The errors are not all .dlls. There are 7 errors about .dlls, 1 .xml file, 1 .pak file, and an exe. But they are all [WinError 5].
The relevant Python 3.10.2 code is straightforward:
# Copy source file to destination if not there.
if not Path(dpath).exists():
shutil.copyfile(ps, dpath)
# Delete source file from its directory.
os.remove(ps)
# Create a symlink in the source file's directory to dpath.
# Program needs to run "as admin" on Windows.
os.symlink(dpath, ps)
So the remove() is failing because Windows is denying access. I don't see how that is possible given the precautions above. Must I run the program directly from the Administrator account to avoid the error? That would be a problem since I'm pretty sure I never gave that account a password when I installed Windows.
Some programs run even in safe mode. You could try to find any services that might be using those files and stop them, but that might not be enough. Like you said, the problem is deletion, so I would recommend copying rather than deleting. Then, you can create a bootable Windows USB drive and boot from that, to finish the deletion and create the symlinks. (You might be able to use a Linux USB drive, but some of them don't support NTFS by default)
I am attempting to mount a file from my Windows (Host) to my Linux (Container). When I mount a single file with a standard extension, everything seems to work fine. However, when I attempt to mount a single file that is a dot-file, it does not work.
//This does not work
type=bind,source=${env:USERPROFILE}\\.sample,target=/home/.sample,consistency=cached
// This does work
type=bind,source=${env:USERPROFILE}\\sample.txt,target=/home/sample.txt,consistency=cached
I'm not sure how to specify that the file is a dot file. I did notice that if the file did not exist, a folder named .sample was created on my Windows (Host) machine, but that same folder was not created on Linux (Container).
Are you sure they aren't there? Linux treats dotfiles as hidden files, so they aren't visible by just doing an ls command.
You can use ls -A which should show you the hidden dotfiles.
As the title suggests, if I paste a c file written somewhere else into the root directory of the Linux Subsystem, I can't compile it.
I did a test where I made two differently titled hello world programs: one in vi that I can get into from the bash interface, and one elsewhere. When I compiled the one made in vi, it worked fine. Trying to do so for the one made elsewhere (after pasting it into the root directory), however, resulted in this:
gcc: error: helloWorld2.c: Input/output error
gcc: fatal error: no input files
compilation terminated
Any help with this would be much appreciated.
Do not change Linux files using Windows apps and tools!
Assuming what you meant by "paste a C file written somewhere else into the root directory of the Linux subsystem" is that you pasted your file into %localappdata%\lxss, this is explicitly unsupported. Files natively created via Linux syscalls in this area have UNIX metadata, which files natively created with Windows tools don't have.
Use /mnt/c (and the like) to access your Windows files from Linux; don't try to modify Linux files from Windows.
Quoting from the Microsoft blog linked at the top of this answer (emphasis from the original):
Therefore, be sure to follow these two rules in order to avoid losing files, and/or corrupting your data:
DO store files in your Windows filesystem that you want to create/modify using Windows tools AND Linux tools
DO NOT create / modify Linux files from Windows apps, tools, scripts or consoles
You cannot copy (by default, who knows how Windows bash is set up!) files into the root directory! Your gcc error is say "no input files", so the copy has most likely failed. Copy the files to your home directory instead, for instance:
cp helloWorld2.c ~/
instead of:
cp helloWorld2.c /
I have a zip file thats titled like so file1.zip,file2.zip,file3.zip,etc...
How do I go about extracting these files together correctly? They should produce one output file.
Thanks for the help!
First, rename them to "file.zip", "file.z01", "file.z02", etc. as Info-ZIP expects them to be named, and then unzip the first file. Info-ZIP will iterate through the split files as expected.
I found a way. I had to mount the remote machines user home folder on my Ubuntu desktop pc and use File Roller Archive Manager, which is just listed as Archive Manger in Ubuntu 18.
Mount remote home folder on local machine...
Install sshfs
sudo apt install sshfs
Make a directory for the mount. Replace remote with whatever folder name you want
mkdir remote
Mount the remote file system locally replacing linuxusername with the user account you want to use to login and xxx.* with its IP address or hostname.
sudo sshfs -o allow_other linuxusername#xxx.xxx.xxx.xxx:/ remote
Now in the mounted "remote" folder you can see the contents of the whole linux filesystem and navigate them in a File Manager just like your local file system, limited by user privileges of course where you can only write to the home folder of the remote user account.
Using Archive Manager I openened up the .zip file of the spanned set (not the .z01, .z02 etc files) and extracted inside the "remote" folder. I saw no indication of extraction progress, the bar stayed at 0% until it was complete. Other X Windows based archive applications might work.
This is slow, about 3-5 megabytes per second on my LAN. I noticed Archive Manager use 7z to extract but do not know how as 7z is not supposed to support spanned sets.
Also if your ssh server is dropbear instead of openssl's sshd it will be unbearably slow for large files. I had to extract a 160gb archive and the source filesystem was fat32 so was not able to combine the spanned set into one zip file as it has a 4gb file size limit.
InnoSetup appears to be corrupting my executable when compiling the setup project.
Executing the source file works fine, but executing the file after installation produces Win32 error 1006 "The volume for a file has been externally altered".
I've tried disabling compression and setting various flags, to no avail.
Has anyone experienced this?
UPDATE
Okay there's been some twists to the situation:
At the moment, I can even manually copy a working file to the location it is installed to and get "The volume for a file...". To be clear: I uninstall the application, create the same folder and paste the files there and run.
UPDATE 2
Some more details for those that want it:
The InnoSetup script is compiled by FinalBuilder using output from msbuild, also executed by FinalBuilder, running on my machine with XP SP3. The executable is a C# .Net assembly compiled in configuration Release|AnyCPU. The file works when executed in the folder the Install Script takes it from. It produces the same behaviour on an XP Virtual Machine. The MD5 hashes of the source file and the installed file are the same.
Ok, I just received this same error. I have a config which my executable uses. I looked in my folder a million times - but finally notice the config file was zero length. I corrected the config and the error stopped occurring.
Check the simplest things first... good lucK!
ERROR_FILE_INVALID
1006 (0x3EE): The volume for a file has been externally altered so that the opened file is no longer valid.
I suspect you're having this issue after moving the files to a network share. It seems to me that what's happening is you have an open file-handle - possibly to a temporary file you are creating - and then some other process (perhaps running on a different host) is coming along and renaming or deleting that file or its' parent directory tree.
So my advice is:
Try installing to a local directory
Run after an anti-virus scan, in
safe-mode or on a different machine
to see if there isn't some
background nasty changing
volume/directory properties while
your program is running.
Make sure the program itself isn't doing anything weird with the volume or directory tree you're working with.
Never seen that before. I've got a few questions and suggestions:
- Are you signing the EXE during the compile of the setup? If so, try leaving that part out.
- WHat OS are you installing on or does it happen on all machines you've tried?
- Run the install with the /LOG="c:\install.log" option and post the log. It might show something happening during install.
- Run a byte compare or MD5 check on the source EXE and the installed EXE. Are they the same? Do they have the same version resource?