Windows doesn't allow you to give files reserved names, such as con. However, WSL doesn't place any such restriction.
Creating a file called con produces an error: 'The specified device name is invalid.' Creating one with
touch con
in WSL does not produce any error, but then deleting it from Windows Explorer produces an error: 'Invalid file handle.' However,
rm con
in WSL deletes it without issue.
What is going on here? Why does WSL create a file with a reserved name without errors?
Windows blocks these file names from using them completely.(if e.g. you accessed a directory C:\CON\CON in an old windows version, you got a bluescreen)
So, you cannot access/create/delete them with cmd or explorer(It does not matter in which drive).
Howewer, the Filesystem does not block it. Because of this linux(maybe because something runs in the Windows Kernel?) shell emulators like git bash or wsl (I did not test cygwin) can create/access/delete these files even in the bootable Windows Partition.
Related
I've created a directory using QDir but the given name had two dots in the end, Qt created this directory although its bad naming, and now my windows 10 OS cannot operate on this invalid directory.
I cannot do any operation on it.
I've done these:
run chkdsk with fixing flags, ...
run check disk utility in drive properties
trying to remove it from command line in cmd and powershell
trying to delete the directory using QDir
What should I do?
Try
RemoveDirectoryW(L"\\\\?\\C:\\full\\path\\to\\dir..");
Explanation: besides enabling the long path handling as documented, the \\?\ prefix bypasses Win32 path processing, passing the path directly to NT API, so it would go directly to NT kernel.
Make sure you use RemoveDirectoryW, not RemoveDirectoryA, a fully qualified path, and backwards slashes '\\' (not /). Due to C++ esaping in string literals, \\?\C:\path becomes "\\\\?\\C:\\path".
I just spent some time messing around with my environment variables. I used to be able to type "atom [filename]" into the command prompt and it would open the file in atom (provided I was in the correct directory). Now when I try this, I get the following message:
'atom' is not recognized as an internal or external command,
operable program or batch file.
I've looked at several threads about this and I have added the path:
C:\Users\[username]\AppData\Local\atom\bin
to my Path variables (both user and system). Why is it still not working? It has worked in the past and I'm not sure what has changed.
1/3/2019 Update:
I can open it if I type atom.cmd, but when I removed the .cmd extension and it stopped working. I still am not quite sure why it can't be recognized as a command without this extension as my computer did used to be able to recognize it.
Found the issue:
In my system variable PATHEXT, I did not have the extension cmd, just CMD. These extensions are clearly case sensitive, because adding cmd fixed the problem.
I am trying to use os.remove() to delete an empty folder in Windows using Lua but it just results in 'Permission Denied'. I can delete files with no problem.
However if I use os.execute() to call rmdir the folder does get deleted.
What are the limitations with os.remove() in a Windows environment?
The os.remove documentation states:
Deletes the file (or empty directory, on POSIX systems) with the
given name. If this function fails, it returns nil, plus a
string describing the error and the error code.
Windows is not POSIX compliant OS, therefore; exhibiting such a behaviour.
To get POSIX compatibility in Windows 7, you have to activate the Subsystem for UNIX-based applications (SUA / Interix) in Windows.
I've been trying to install the 64bit version of PostgreSQL 9.2 for Windows on my machine (Windows 7 64bit) and get this error:
The environment variable COMPSPEC does not seem to point to the cmd.exe or there is a trailing semi colon present.
I've installed it as Administrator.
I disabled the antivirus (Microsoft Security Essentials) and the firewall.
Running:
"%COMSPEC%" /C "echo test ok"
returned test ok
I've checked my System Environment Variables for trailing semi colon and I couldn't find any.
I then installed the 32bit version and managed to get to the end of the install with a different error message stating: Problem running post-install step. Installation may not complete correctly Error reading the C:\Program Files (x86)\PostgreSQL\9.2\data\postgresql.conf but there is no postgresql.conf file in that directory. It did install the application and when I try to connect the server with the red X on it it says fail at the bottom and it won't connect after I type in my password.
How can I connect to this server connection?
ComSpec is a generic error message for any installation failure.
Identifying the problem
Navigate to below path
c:\Users\XXXXXX\AppData\Local\Temp
Open 'bitrock_installer_XXXX.log'
Check, if you are getting below error:
Script stderr:
'"C:\Users\XXXXX\AppData\Local\Temp\POSTGR~1\TEMP_C~1.BAT"' is not recognized as an internal or external command, operable program or batch file.
Error running
C:\Users\XXXXX\AppData\Local\Temp/postgresql_installer_47b21c4ea1/temp_check_comspec.bat :
'"C:\Users\XXXXX\AppData\Local\Temp\POSTGR~1\TEMP_C~1.BAT"' is not recognized as an internal or external command,
operable program or batch file.
This is a problem with '8.3 file names and directories' (e.g. '\Postgres Install' -> '\POSTGR~1')
Microsoft article on disabling 8.3 file names and directories: https://support.microsoft.com/en-gb/kb/121007
Solution:
Open command prompt in admin mode
Execute following command to change the format based on your drive or all drives
Sample commands:
fsutil 8dot3name set 1" - disable 8dot3 name creation on all volumes
fsutil 8dot3name set C: 1" - disable 8dot3 name creation on c:
Execute the installation as a user having admin privileges
After install, consider resetting the 8dot3name setting to default (2) to avoid unintended consequences
Hope it solves the problem!
Very easy fix:
Just open Advanced System Settings in Control Panel and create a new System Variable( in the System Variable instead of User Variable section).
In the variable name, enter ComSpec and then in the variable value , enter C:\Windows\system32\cmd.exe.
Alternative fix:
If you have already the ComSpec variable in the System Variable section, remove the ;at the end of it this should fix it.
It's not COMPSPEC it's just COMSPEC. Please show the output of:
echo %COMSPEC%
Note that COMSPEC could be set to something different in the Administrator account you're running the installer as. I'm not sure how to find that out, but it might appear in the PostgreSQL installer log, so please upload that and link to it in your post. See Reporting an installation error for info on where to get the installer log.
See the PostgreSQL for Windows FAQ entry Check the COMSPEC environment variable.
Here's a report I made suggesting that the installer should test for this explicitly and here's my blog post on the topic.
I got the same problem, and i found in the log:
Script stderr:
'C:\Users\S300' is not recognized as an internal or external command,
operable program or batch file.
Error running C:\Users\S300 (i5)\AppData\Local\Temp/postgresql_installer_56caeadbd6/temp_check_comspec.bat : 'C:\Users\S300' is not recognized as an internal or external command,
operable program or batch file.
I change in User Variables TEMP to D:\TEMP and TMP to D:\TEMP.
And Solved My Problem.
In my case , the Installer was in %USERPROFILE%\DownloadsP{ Windows download folder}, I moved the installer to desktop and ran again. weird it worked lol.
I had a similar problem. After installation, the data folder contained no postgres.conf file. It only contained a single folder named "pg_log".
I described the solution that I used here: Postgres Installation Error reading file postgresql.conf
Basically, it would be helpful to check if the user has full permissions for the postgres folder, and run "init_db" and "pg_ctl start" commands again. If the path contains a space character, try using a relative path for the pg_ctl data folder argument.
I'm running Windows Server 2003 R2, and I have been unable to resolve this problem with the installer, so I resorted to using the binary PostgreSQL package. Hopefully this will be an alternative for others who do not want to perform an OS reinstall.
First, some background (hopefully useful to the developers)
It started out with the postgres service failing to start (the server had been running reliably for over a year). I assumed it was a corrupted PostgreSQL installation, so I uninstalled and attempted to reinstall. I encountered the following error:
There has been an error.
The environment variable COMSPEC does not seem to point to the cmd.exe or there is a trailing semicolon present.
Please fix this variable and restart installation.
However, the COMSPEC variable is set properly, verified with:
echo %COMSPEC%
C:\WINDOWS\system32\cmd.exe
and:
"%COMSPEC%" /C "echo test ok"
test ok
Since this is Windows Server 2003, there is no UCA wrapper around the Administrator account, so that is not causing the problem.
Manual Installation
NET USER postgres /ADD
C:\pgsql\bin\initdb.exe -U postgres -A password -E utf8 -W -D C:\pgsql\data
runas /user:postgres "C:\pgsql\bin\pg_ctl -D C:/pgsql/data -l C:/pgsql/logfile.txt start"
just do it run as administrator and change the environment system variable
like create a new variable 'ComSpec' and value type 'C:\Windows\system32\cmd.exe'.
If the installer exe is on a network share that mapped drive might actually not be accessible to the installer as it runs as administrator. This can often happen in some virtual machine arrangements such as running windows in a parallels VM. Copy the installer to a local drive first and you won't have a problem.
What worked for me after trying to enter the commandline given her in cmd.exe
I found it was named cmd1.exe in system32.. so i copied the file and renamed it as cmd.exe and installation finished
Open Environment Variables, you can do this on Windows 7 by typing environment variables in the Search program and files bar when pressing the start button at the bottom left of the desktop. And create a new System Variable(in the 'System Variable' instead of 'User Variable' section).
In the variable name, enter ComSpec and then in the variable value , enter C:\Windows\system32\cmd.exe.
That's all. Hope it works!
Alternative fix:
If you already got the ComSpec variable in the System Variable section, remove the ; at the end of it this should fix it.
First find the path to cmd.exe(mostly it is C:\Windows\System32\cmd.exe).
Go to the enviornment variable and add this path to system variable path.And also create new variable in user variable called ComSpec and add this path as value. And you are ready to go.
I have Cygwin running on a Windows 7 machine and have the Cygwin ssh server running on it. On Linux I have a shell script where I want to do
ssh myuser#mymachine "qwinsta | grep Active"
to see who is logged in. This worked fine for a Windows Server 2008 R2 machine, but seems to have problems on Windows 7.
If I try this on the Windows 7 machine, I get:
bash: qwinsta: command not found
Now, here is where the weirdness begins...
If I login to the Windows 7 machine normally and look in C:\Windows\System32 with Windows Explorer, I see qwinsta.exe. If I open a CMD session and do a dir in C:\Windows\System32, I see qwinsta.exe. If I open a Cygwin shell and do a ls qwinsta.exe in /cygdrive/c/Windows/System32, I get:
ls: cannot access qwinsta.exe: No such file or directory
If I do a cmd /c dir C:\\\\Windows\\\\System32\\\\qwinsta.exe from the Cygwin shell, I get a "File Not Found"
If I copy qwinsta.exe into my Cygwin home directory, then it is visible in my home directory with ls. If I try to run this local copy of qwinsta from the Cygwin shell, it runs, but it also outputs a line:
{Message(): LoadString failed, Error 15105, (0x00003B01)}
What's up with qwinsta on Windows 7?
The problem is that qwinsta.exe is not actually located in C:\Windows\System32. It is actually found in
C:\Windows\winsxs\amd64_microsoft-windows-t..commandlinetoolsmqq_31bf3856ad364e35_6.XX.XXX.XXXX_none_XXXXXXXX\qwinsta.exe
Using the above path (or a softlink to the same) will run qwinsta.exe as it exists on any machine, and will not require you to copy the executable to your home directory.
The error message {Message(): LoadString failed, Error 15105, (0x00003B01)} is about the Multilinugal User Interface (localization) system not being able to find error message localization information for the program being run (see System Error Codes). In this case, it appears that the cygwin shell does not provide qwinsta.exe with the information it needs to find qwinsta.exe.mui in your language's locale folder (usually C:\Windows\System32\en-US or whatever your locale happens to be). Looking into this folder is somewhat misleading, as explorer will show the file in this directory, but when you run ls /cygdrive/c/Windows/System32/en-US, there is no qwinsta.exe.mui file. I suspect this has something to do with the new linking structure in NTFS (see mklink command), but I haven't figured out how to fix this part of the problem yet.
Solved:
First, go to C:\Windows\winsxs\amd64_microsoft-windows-t..commandlinetoolsmqq_31bf3856ad364e35_6.1.7600.16385_none_851e6308c5b62529
(Copy and pasting that location works just as well as manually finding it.)
You should find three files: Msg.exe , Quser.exe, and qwinsta.exe .
Copy these files to your C:\Windows\system32 folder
Next, go to C:\Windows\winsxs\amd64_microsoft-windows-t..etoolsmqq.resources_31bf3856ad364e35_6.1.7600.16385_en-us_7bef78d9f4a6a8ac
You should find three similarly named files, except these will end with .mui.
Copy all three of these files to your C:\Windows\system32\en-US folder.
Now try running the msg program. It should work without issue.
Windows 10
Following on from Erutan2099's answer, for Windows 10 it's a little trickier, since the files are compressed (binary delta compression, file signature 44 43 53 01). Trying to use them as is throws an Unsupported 16-Bit Application error:
The program or feature "\??\C:\Windows\System32\msg.exe" cannot start or run due to incompatibility with 64-bit versions of Windows. Please contact the software vendor to ask if a 64-bit Windows compatible version is available.
A specific tool has been made to decompress such files: SXSEXP (this post pointed me in the right direction)
Usage:
> sxsexp64.exe msg.exe expand\msg.exe
Processing target path msg.exe
msg.exe => expand\msg.exe
File size 12602 bytes
DCS_HEADER found.
NumberOfBlocks 1
UncompressedFileSize 26112
DCS_BLOCK #1
Block->CompressedBlockSize 0000312A
Block->DecompressedBlockSize 00006600
Operation Successful
> sxsexp64.exe msg.exe.mui expand\msg.exe.mui
Processing target path msg.exe.mui
msg.exe.mui => expand\msg.exe.mui
File size 2150 bytes
DCS_HEADER found.
NumberOfBlocks 1
UncompressedFileSize 7680
DCS_BLOCK #1
Block->CompressedBlockSize 00000856
Block->DecompressedBlockSize 00001E00
Operation Successful
These decompressed files can now be copied to C:\Windows\System32 and C:\Windows\System32\en-US respectively.
Example:
> msg * Hello, World!