I received a message from OneDrive stating that files had been deleted and asking if I'd like to restore them. The files where from my React project node_modules folder. I restored the files and everything is working fine. I'm wondering why this might have happened. Any insight would be appreciated.
Related
I've got a pretty simple repository made up of a frontend folder in which I have a react app, and a backend folder that is mostly empty for now.
Every few minutes, regardless of whether or not I make any changes to any files, some node_modules file will pop up in GitHub desktop showing a difference.
screenshot of my github desktop
Do I need to add node_modules to my .gitignore file?
This didn't happen before, I don't know what happened to trigger this. I add the changes because I assume it's an important node_modules update but then it happens again a few minutes later.
I'd like to understand why this is happening and how I can prevent it from happening as it makes my commit history impossible to read.
Simplest solution would be to gitignore node modules like so...
/node_modules
Unless you have a specific reason to track changes to npm?
It's usually better to install fresh packages via npm install when setting up on a different enviroment/device.
I have a project under source control using TFS and Azure DevOps.
It all works normally except for one thing: When I check in a file, I get this error message:
TF10122: The path '$/KnowledgeBuilder/V2/$tf/1/1f8c47a1-8066-42d7-b56c-c9960b0ee7ea.gz' contains a '$' at the beginning of a path component. Remove the '$' and try again.
The check-in does in fact succeed, but I get three of the above error messages each time. I can simply ignore this, but it is starting to get annoying.
It appears the folder in question is a TFS created and controlled folder. I tried deleting the folder, but that remove the Project from Source Control, so I restored them.
Is there a way to resolve this?
This occurs in VS22 on a Blazor Server Project. I have tried opening the Project in VS19, making a change, and then checking it in, and it works fine. So, it must be something specific to VS22.
Someone, sometime, at some point, added that $tf folder to version control. It should not be there, ever, under any circumstances -- that's the folder that TFVC uses to track local workspaces. That's why removing it messes up your workspace.
Make sure any pending changes are committed or shelved first.
Remove that folder from source control. Make sure the change is checked in. You might need to use a server workspace to do this so that the $tf folder isn't relevant.
Use tf get to force a re-sync of your local workspace. tf get /all /overwrite should do the trick. If it doesn't, then just delete and recreate the workspace.
Add $tf to your .tfignore file (although if memory serves, that shouldn't be strictly necessary -- I haven't worked with TFVC in a few years)
I was wondering if anyone else has come across subfolders of node_modules randomly disappearing on Mac, not the entire directory but the odd dependency?
All my projects are on my desktop and randomly I get errors running a project where a node module has suddenly disappeared, I say disappeared but they actually appear to be there, the only way I've figured of correcting the issue is to delete the entire node_modules directory and reinstall?
I can't say I've ever come across this previously, my desktop does backup to iCloud, aside from that I can't think of anything else that would cause this - any ideas?
So it turns out for anyone that has the issue you need to disable iCloud backup/sync on the folders with your node modules projects, somehow MacOS seems to break the folder structure - I'm not quite sure why yet...
Am trying to publish my Web Application. It worked fine literally 15 minutes ago and not aware of anything changing in the meantime. Now receiving this error:
Copying file bin\myApp.dll to obj\Release\Package\PackageTmp\bin\myApp.dll failed. Could not find a part of the path 'obj\Release\Package\PackageTmp\bin\myApp.dll'.
Tried copying the dll manually and Windows just hangs.
Any ideas?
Usually this happens to me when a file is locked (still in use) by windows.
Try right clicking on the solution and doing "clean" solution. Then rebuilding.
If that does not work. Try cleaning solution, closing Visual Studio, re-opening it, then publishing it.
Think I've fixed it. Had to remote directly into the server and cut the release folder to the desktop then copy it back again. Window's threw some permission errors, which it shouldn't have as I have full permissions but worked when I clicked "Try Again". Then manually inserted the dll the same way and tried publishing again. This time it worked. Bit of a weird one but seems to be working now.
I was looking for a solution to this problem and I've found out, in my case, that the folder was not being created when the project was published in IIS. So I've copied the folder from my project's directory to the location where the project is published.
It worked for me!
I had a similar issue and found that the cause was the permission set in the Build folder located in the project folder where the software is compiled to.
For some reason the permission were not set to full, and on further investigation the delete permissions were not set to active.
This meant that the first compile succeeded, but the second failed because the original folder could not be cleared by Visual Studio, or the original files could not be overwritten.
Setting the permissions to full fixed this issue.
This happened to me when you have a files that the path that is longer than 255 chars.
Ensuring all file paths from the drive root to all the files in the Debug\Package\PackageTmp folder were shorter than 255 corrected the issue for me
I did a Get Latest from the root folder ($) of a Source Safe database and all I got is all the folders hierarchy. There were no files anywhere. But if I do a Get Latest on each folder (project), I do the files for that folder hiearachy.
Why does this happen? Is this a permissions issue?
I have the same question... It plays when checking out a toplevel project ($/Projects)
Below that is ok ($/Project/Demo1) works
-- EDIT: Solved
With patience the files started appearing after all. I know for sure that it had finished before, but that was on a copy of SSEXP started from withing visual studio 2008. Perhaps some memory restriction plays a role (makes it fail for large volumes of trees with many files, without displaying a proper error message?).
Anyhow, redoing the get from a SSEXP started with Visual Studio closed (and applying LOTS of patience) worked for me in the end