I ran a program on Windows 7 that was compiled under Cygwin and passed "NUL" as an output file name. Instead of suppressing output it actually created a file named "NUL" in the current directory. (Apparently it expects "/dev/null", even on Windows.) Now I'm stuck with this "NUL" file that I cannot delete!
I've already tried:
Windows Explorer - error: "Invalid MS-DOS function" (yes, that is seriously what it says!)
Command prompt using "del NUL" - error: "The filename, directory name, or volume
label syntax is incorrect."
Deleting the entire directory - same deal as just deleting the file
remove() in a C program - also fails
How can I get rid of these NUL files (I have several by now), short of installing the full Cygwin environment and compiling a C program under Cygwin to do it?
Open a command prompt and use these commands to first rename and then delete the NUL file:
C:\> rename \\.\C:\..\NUL. deletefile.txt
C:\> del deletefile.txt
Using the \\.\ prefix tells the high-level file I/O functions to pass the filename unparsed to the device driver - this way you can access otherwise invalid names.
Read this article about valid file / path names in Windows and the various reserved names.
If you have Git for Windows Installed (v2.18) do the following
Open the directory containing the files you want to remove
Left Click and select Git Bash Here
Type rm nul.json at the command prompt and hit ENTER, the file now should be removed.
NOTE: These screenshots show the removal of file nul.topo.json which is another file that I could not removed with a simple delete.
If you have git on windows, just right click on the folder containing the nul file -> go to gitbash here -> and type "rm nul" or "rm nul.json" depending upon the file type.
I had a similar issue. It was probably caused by Cygwin as well (since I use this regularly), but I've since forgotten exactly how the file was created.
I also had trouble deleting it. I followed the advice of some other posts and tried booting into safe mode to delete the file, though this did nothing. The tip from +xxbbcc didn't work for me either.
However, I was able to delete the file using the Cygwin terminal! Cygwin createth and Cygwin destroyeth.
To remove a nul file situated here:
C:\unix\cygwin\dev\nul
I simply use (tested only on Windows 10) :
Del \?\C:\unix\cygwin\dev\NUL
I solved this in a slightly different way.
I thought I would add this here because it is high in the google results and I had a similar issue for a folder named NUL.
I tried rmdir\\?\C:\My\Path\NUL and rmdir\\.\C:\My\Path\NUL without any success and also tried several commands using bash from my SourceTree installation. No joy.
In the end I used DIR /X /A from cmd to list the short names in the parent directory. This showed me NUL~1 for my NUL folder and identified the crux of the problem.
This was then used in the standard command rmdir /s NUL~1 and finally resolved the issue.
I was having this same issue.
If you have WSL2 installed just go to that directory and run:
rm -f nul
In my case the file was lowercase. You should be good.
Try writing a short C program that calls the Windows API to delete that file.
http://msdn.microsoft.com/en-us/library/aa363915%28v=vs.85%29.aspx
If that doesn't work, try opening a handle to the file with CreateFile() with FILE_FLAG_DELETE_ON_CLOSE, and then close the handle.
Related
Description:
I am searching a very large server for files that is on a different server. right now I open command prompt and type
DIR [FILE NAME] /S/4
This returns the server location of the file with some other stuff that is not really needed.
Question:
I have a lot of files to search and one by one input into the above command could take forever. Is there a way I could input all of the names of all the files and only search once and the search results would only need to show file name and location?
First, I hope you don't mean DOS, but rather Windows cmd or batch.
You can certainly write a script that will run your DIR command once per file being sought.
But what you most likely want instead is to search once and print the path of each file found. For this you can use PowerShell's FindChildItem or the improved one posted here: http://windows-powershell-scripts.blogspot.in/2009/08/unix-linux-find-equivalent-in.html
It will be something like:
Find-ChildItem -Name "firstfile.txt|secondfile.txt|..."
Another approach is to install msys or cygwin or another Linux tools environment for Windows and use the Linux find command.
I'm running an exe with multiple arguments that may or may not contain spaces. I encloses them with quotes but they are somehow not passed to the exe correctly.
Here's the command i'm using:
makeblastdb -in "D:\d b\sequence.fasta" -input_type fasta -dbtype prot -title xd -out "D:\d b\xd"
which I think cmd should pass 10 arguments to the exe but somehow it isn't passing correctly.
this is the result i get
BLAST options error: File "D:\d" does not exist.
which is basically saying that the second argument is being chopped for some reason?
Any help will be appreciated, thanks!
Based on your comments to your question, the BLAST utility does not properly handle quoted paths with spaces, and your volume does not support short file names.
Obviously you can move your working directory to a path that does not contain spaces.
An alternative is to use SUBST to temporarily create a virtual drive that points to your problematic path.
subst K: "d:\d b"
makeblastdb -in "K:\sequence.fasta" -input_type fasta -dbtype prot -title xd -out "K:\xd"
subst /d K:
Type subst /? for help with the command.
Update based on fact that you are running the command from within python
In your comment to this answer, you state you will attempt to get the command to work from within python. That could be the entire source of your problem.
You should try to run the command in your question directly from a Windows command prompt (cmd.exe console).
If the command does not work from the command prompt, then the problem is indeed with the BLAST utility, and SUBST is a good solution.
If the command does work from the command prompt, then the problem is with how you are shelling out the command from python, and the SUBST command should not be required.
I'm not a python user, but I see that many people have similar problems when using python on Windows. Perhaps this will help: How do I execute a program from python? os.system fails due to spaces in path
makeblastdb has an odd escaping convention. Try this:
-in \""D:\d b\sequence.fasta"\"
Unfortunately this doesn't work for -out, so dbenham's answer is probably best.
Alternative is you can try using directory shortname for "D:\d b" which you can find by running dir /X command on your D drive. For instance if I run dir /X on my C drive here is what I get:
01/21/2013 09:47 AM <DIR> PROGRA~1 Program Files
So you want to use C:\Program Files you can alternatively use C:\PROGRA~1.
I'm looking at a batch file and I see the line below. I know what %LOG% is, but I do not know what the "rm" command is doing. Can anyone tell me?
rm "%LOG%"
rm is a commandlet in Windows Powershell.
NAME:
Remove-Item
SYNOPSIS:
Deletes the specified items.
DESCRIPTION:
The Remove-Item cmdlet deletes one or more items. Because it is supported
by many providers, it can delete many
different types of items, including
files, directories, registry keys,
variables, aliases, and functions.
%LOG% is a variable defined in that batch file using
set LOG="Something"
(NOTE: It is not a global Variable or alias)
So what it will do is delete the item pointed by variable LOG.
The rm is a command that's being run, rather than anything special for the batch file. Does the system which ran this batch file include the cygwin package? That provides Windows / DOS versions of various standard unix utilities, including rm - which is the remove command - similar to del on such boxes.
%LOG% - variable that contain path to log file and that command remove it.
rm is not a standard ms-dos command. If you type it on the command line, what comes up?
perhaps it is short for rmdir (a synonym of rd) which removes the specified directory.
rm is the *NIX version of del
so its deleting %LOG%, unless it fails b/s its not a command on Windows. ( PowwerShell maybe)
Even if this is not Unix, rm is going to be a command to delete a file. For example, see http://www.mkssoftware.com/docs/man1/rm.1.asp or http://www.cygwin.com/
I have a strange file in my file system without the extension part. The filename is "15.". The weird thing is that it is not one of those without the dot part (like just "15"), but the one with the dot but no extension ("15.") -- it is literally an illegal filename in windows, and not sure how did it get created in the first place.
I know it is a text file and it is about 15KB in size; however, due to the weirdness in name, I can't open it with any application -- I've tried to open in notepad, wordpad, etc., have tried the 'type' command to spit it out on commans shell, tried to shell-open enclosing filename in quotes, and so on -- all methods result in a 'file not found' error except the notepad, which says '15.txt' is not found.
Due to the nature of the issue and the way search engines optimize the search, it is extemely hard to search for an answer in any of the search engines online. So, I just wanted to put this question out there and see if anybody had to deal with a similar issue and have found any way to rename the file or even to change the extension.
Filenames that are valid in NTFS but cannot be used from Windows can be created when accesing disks or shares from other operating systems like Linux.
If you don't have a Linux installation at hand, then get hold of a "live" CD, boot Linux, and change the filename.
That may sound like a hassle, but Windows-only solutions (moving stuff around, deleting the directory) are even worse.
Use REN: http://ss64.com/nt/ren.html
It is a command prompt command (run > cmd > cd wherever > ren 15. 15.txt )
This is what I get when trying to compile a simple hello world program with gcc.
c:\>gcc hello.c
hello.c:9:2: warning: no newline at end of file
C:\MinGW\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe: cannot open output file a.exe
: Permission denied
collect2: ld returned 1 exit status
Does it have something to do with windows 7 administrative privileges?
If the output file is being created but cannot be opened, where is it located?
Sorry if this is too much of a noobie question. I have been using Dev-C++ for compiling my source code till now. I tried googling around the error but all i could find was the file is already open, but there is no mention of such exe in task manager.
Edit: Also the file is located at C:\hello.c
Will i be able to do it if i place it in other drive?
When i place the file at D:\ and try change it to any other drive using cd d:\ doesn't change the drive.
Yes it is a permissions issue, you must not be running the command line window in Admin mode.
Don't work in C:\
Copy the file to a folder under my documents, or a subfolder of C:, or another drive.
Or, run the console in Administrator mode if you really want to work in the root of C:
To switch to D: while in C:, just type D: (you use CD only when already on the correct drive)
The most common case is that your program may still be running in the background, possibly hanged on an endless loop. You can try searching for the process in the process list (press Alt+Ctrl+Del) and killing it.
I found problem was hosting src under google drive;.. jesus super star chuck norris van damm .. 3h trying to figure out this one (vs code + mingw64).
Solution:
Just moved the folder with my cpp source file outside google drive managed folder tree (was on f:\gd) so moved my source into f:\dev.
The g++.exe-command in the build-log in the CodeBlocks-IDE shows the command
with an additional path: C:\MinGW\lib, which is wrong.
If you copy the command to a cmd-window (in the directory of your Project)
without the C:\MinGW\lib the compiler works. When you copy the command as shown in CodeBlocks-Buil-log it fails, with the same message in the cmd-window.
Have a look at the Settings > Compiler > Search Directories > Linker. You've got to delete the
C:\MinGW\lib there, but the bug is, that it is not deleted if you do it once.
You've got to repeat it and then it works.