I just wasted an hour or so chasing this. I was able to resolve it but putting it in q/a form hoping others might benefit.
The symptom was that I could not access a directory. I could browse to it in explorer or command window. I could not even see its security permissions in properties window.
The folder is created by our build process, which meant I could pretty much do no work. Searching on net was no help.
Answer below.
It turns out it has to do with how cygwin does not lock a directory. The build process removed the directory (rmdir /s u:\target) and then recreated it (mkdir u:\target). I had a bash window where that directory was the current directory.
When the build process (bat file) called rmdir it succeeded, even %errorlevel% was 0. However the subsequent mkdir failed with Access is denied.. The build process unfortunately checked only for rmdir failure, not mkdir.
Thanks to handle.exe I found the folder to be in use by bash.exe, From there it was straightforward. Changing the current directory finally deleted the folder and another go at build set everything right.
I realize this is unix behavior to remove a file only after all handled to it are closed, but its simulation in windows is somewhat non-intuitive.
Related
I am trying to use models from Hugging Face, but VS code always downloads them into my very limited C: drive; C:\Users\<user>\.cache.
How can I force it to cache to a different drive?
Things I've tried:
Googling: only seen threads for Linux, whose commands do not transfer over. Could not find clear equivalent commands for Windows.
Running a new instance from terminal code --user-data-dir E:/.cache
Fully un-installing VS Code, downloading a portable version, and making a data folder (following these instructions)
All of them still result in caching to C:\Users\<user>\.cache.
From some further research, it appears this is currently not possible.
However, I've found that symlinks is a great temporary workaround. In short,
Create a folder on a drive/partition with an abundance of space, i.e. E:\TempCache
Close any instances of VS Code, if any.
Navigate to C:\Users\<username>\.cache. If there's anything in it, cut them over to E:\TempCache, and delete the whole .cache folder.
Open cmd with admin rights, and enter mklink /J "C:\Users\<name>\.cache" "E:\TempCache". This will re-create an empty .cache folder.
Next time VS Code is ran, it will automatically detect and use the .cache folder on the C drive like nothing changed.
So I'm trying to change the directory the integrated terminal runs my Python scripts in from the root workspace (the default, I guess) to the running file directory. I want to do this as I'm more used to work with paths relative to running file than to root dir. Also sometimes I use quite large directory trees and even paths to near directory files get quite long by starting them from root dir. This would also allow me to use Path Intellisense extension as it seems to base suggestions on the current file dir.
I heard about changing the lauch.json file but I'm looking for a definitive solution that avoids having to change this in all projects.
I have already tried to change settings.json cwd option to "terminal.integrated.cwd": "${fileDirname}" but it doesn´t seem to take any effect, even after reloading.
I'm not sure what other infos are relevant here, but nevertheless i'm running vscode on windows 11 version 21H2. Any other info feel free to ask.
Thank you all in advance
Have a perplexing bug when I try to reconcile work through the CLI for perforce in that I get a large amount of files detected and added to the changelist whenever I run the command.
This happens regardless of where my current working directory is but the files always come from there, if my working directory is outside the project's root I get a 'Path {path} is not under client's root' error and they are not added, however if my working directory is under the project root they are detected and added as missing files.
I've tried numerous different combinations of the reconcile command, explicitly stating the port, user, client etc., setting up P4Config, using relative and absolute paths, changing the working directory - but I always get these ghost files.
Has anyone come across this before? Could this be a bug with P4 itself?
Edit: I finally fixed this by reinstalling P4V so I'm assuming this was some bug either my install of perforce or any local config files that would have been reset upon reinstall. For reference this is the page that finally fixed it https://community.perforce.com/s/article/15324
This is the result of the following bug:
https://www.perforce.com/perforce/doc.current/user/relnotes.txt
Bugs fixed in 2020.1 Patch 1 (2020.1/1991450)
...
#1964794 (Job #102470) *
'p4 reconcile'/'p4 status' might report about invalid filenames
of the form '//depot/0' or '//depot/100', etc. This is fixed.
Since this was fixed in a 2020.1 patch, it can be inferred that it only affects specific 2020.1 builds (i.e. those before the patch).
To fix it, make sure you're on a client version (p4 or P4V; this is not a server-side bug) whose changelist number is higher than 1964794. No special reinstallation procedure is needed; just download the latest binary/installer from Perforce's website.
Force a reinstall of P4V to fix this, details can be found here:
https://community.perforce.com/s/article/15324
Or if that page is taken down for any reason:
SOLUTION
Forcing a reinstall using the Windows msiexec installer utility with Windows msi installer file extracted from the p4vinst64.exe file can often successfully complete a full reinstall where running the P4V exe installer such as "p4vinst64.exe" fails
If not already downloaded, obtain the appropiate Windows installer for P4V (for example "p4vinst64.exe" for 64 bit Windows platforms). Currently these can be downloaded from https://www.perforce.com/downloads/helix-visual-client-p4v
Extract the msi from p4vinst64.exe; for example to extract it to "c:\p4v", open a Windows a cmd prompt and change directory to the location where p4vinst64.exe .is located and run the following command:
p4vinst64.exe /s /b"c:\p4v" /v"/qn"
Now from c:\p4v, run the following command to force a full reinstall:
msiexec /i "p4vinst64.msi" /qn REINSTALL=ALL REINSTALLMODE=vamus /L*v log.txt
I'm new to cmder so excuse me if it's a basic question.
So when I open cmder, I keep getting these PATHS as "were unexpected at this time"
An image for the paths that load on startup:
I tried to extract cmder to another folder, delete them from user/system variables and add them according to cmder-github-wiki but I kept getting the same bug/error/hint or whatever it is.
I don't know if it affect my workflow or not but I hate seeing errors before I begin anything! xD
1:
Try the following:
Check your PATH variable for syntax errors, especially near any occurance of Python related things.
Check something like an "autostart.bat" that CMDer runs at every start. The culprit may be located there, near any occurance of PATH or invoking files or directories which do not exist anymore.
Please clarify: What exactly are you invoking and in which directory, to start CMDer / to get this output? Which files did you edit and what are the contents of those files?
As last resort try uninstalling and reinstalling CMDer. The execution is probably broken since the move to another directory you described and the problem might be hard to track.
I have the following instruction in I need to perform to run a web app I that have received:
"Go to the directory where the app is unpacked and type 'gradle jettyRun'."
Sounds simple enough, if you know the commands for finding out your current directory and changing it. The problem is, searching for these basic things only nets a huge amounts of irrelevant answers to much more advanced questions where the same terms are used with a slightly different meaning. So what do they exactly mean by what they say and how do I achieve that? It sound's so simple I'm almost embarrased to have to ask it, yet I'm still dumbfounded by the MySQL command line enough to have to.
This has nothing to do with the MySQL command line (>>>), or MySQL itself. This is simply saying:
Open your terminal or shell. In Windows, this is called Command Prompt.
Change the directory to where the files are located, you do this with the cd (change directory) command.
Next you simply type gradle jettyRun.