I'm having trouble with an application which moves files from one location to another, using the Windows API. The problem isn't the code, it appears to be the project settings, but I don't know what to look for or where.
I created a project, wrote a load of code and then got to implementing the move bit. On testing I kept getting an 'access denied' result. After lots of head scratching I created a new project to unit test the move code. It worked just fine. I copied the known working code wholesale into the original project, deleted everything else and reran it. Access Denied. So the only difference between the two projects is whatever is in the project settings. I also checked the security setting in Explorer for both exe files. Both are the same with me as the owner.
Please can anyone suggest what I need to check/change in the settings? I don't want to wade through trying to compare the both project settings manually.
Many thanks.
For anyone interested the code I'm running is:
#include <windows.h>
#include <string>
#include <stdio.h>
void main(int argc, char** argv)
{
std::string srcPath = "S:\\_UploadTests\\Oct_10";
std::string dstPath = "S:\\_archivedtests\\Oct_10";
BYTE flags;
flags = MOVEFILE_COPY_ALLOWED | MOVEFILE_REPLACE_EXISTING;
if (!MoveFileExA(srcPath.c_str(), dstPath.c_str(), flags)) {
fprintf(stderr, "Error moving folder to local archive. \n\tWindows returned code: %ld\n", GetLastError());
}
getchar();
}
OK, so there were a number of things going on, but I've found the issue.
Firstly and most importantly, it had nothing to do with the Solution settings! The move was being executed as a copy and delete (there' a flag for this option). Sometimes the copy would succeed, but the delete wouldn't and I'd kill the process before Windows could tidy up the mess I'd made. In short sometimes I'd kill the process and sometimes I'd let it terminate naturally, resulting in the file system being in different states, which caused confusion when trying to understand what was going on.
So why was there an issue sometimes when Windows tried to delete the file? Well in my original project I use a function that recursively goes through the folders and collects a list of their contents. This function wasn't releasing the folders on completion, thus causing an access denied error when the later move function tried to do its stuff.
Why did the Access Denied still happen when I tried running the above code snippet above? Dunno, but it's something of a moot point now.
Thanks for the support guys.
Related
I'm trying to commit new changes to my repo, but it fails with the following errors:
error: unable to create temporary file: Invalid argument
error: unable to create temporary file: Invalid argument
error: Error building trees
When others faced similar issues, the error would point to a specific file/object which was causing the issue, however here there is no additional info to go on.
(Windows 10, tried through Terminal and cmd)
I found the issue - the project folder was being synced with OneDrive, which corrupted (The tag present in the reparse point buffer is invalid) one of the files in the objects folder inside .git. Figuring out where the issue lies could be done either visually (for me it was the only folder with blue OneDrive sync arrows instead of the green tick and the folder couldn't be opened). Another way is to clone the problematic branch into a new folder, make a small change (I created a test.txt with "test" written inside), push it to git, then go back to the problematic project folder and try to pull new changes from git. This operation failed and pointed to the corrupted object.
To solve this I looked into how to deal with files which OneDrive corrupted, and the most common suggestion was to run chkdsk c: /r /f in Command Prompt (as admin), which starts when the computer is rebooted. Beware it can take several hours to complete.
General Windows Solution (tested on Windows 10 and 11):
I'm getting the error because it appears that windows put the folder in read only mode
Deselect read only, then click apply and ok
Git really ought to print the path here, yes. The error seems to come from object-file.c:write_loose_object(), which is going to be creating a temporary file within .git/objects in the normal case.
The EINVAL error case should never occur, as the object path itself is necessarily valid (otherwise how did it come into existence?) and the generated temporary file name uses entirely "safe" characters. So the missing filename.buf in the error message should never comes out in the first place. In your case, the error does come out, and the missing %s for filename.buf means we can't see what path it is that your OS is objecting to.
You could build a debug or private version of Git (that adds the missing path) to find out, or use whatever system-call tracing facilities you have to observe the failing system call some other way. Find out why the OS is rejecting the attempt to create the loose object temporary file, and correct whatever the underlying problem may be. Meanwhile you might want to report this to the Git mailing list.
I am working with Visual Studio Code, and when I am starting to code in C, an error message shows up:
include errors detected. Please update your includePath. Squiggles
are disabled for this translation unit
(C:\Users\user\Desktop\c2\main.c)
Any help?
Well, in case you tend to tranfer your code from one system to another, some things may get messed up.
VSCODE creates a specific folder when you start a new project called -you guessed it- "vscode" where some useful information about JSON and the compiler are stored. If you move your project to a different pc and try to open it via vscode, it is likely that the info stored in VSCODE-directory will not apply to this system.
In my case, I had a path like: "Users/user1..." in a system that did not have any user named user1 so i had to configure the VSCODE directory or even delete it altogether and let VSCODE create a new one.
It's been several days since my MS Visual (2013 : 12.0.311001.00 update 4) became kind of nut and behave strangely:
Here are the symptoms
I have a simple hello word project that builds fine.
I insert one mistake into the code (see below).
I build project.
Visual (I'd rather say the compiler) is perfectly find with the new error inserted. It doesn't rebuild nothing and run the previous version of the code.
The mistake is however highlighted in red in Visual editing panel.
here is the code (which is not the guilty here)
include <iostream>
int _tmain(int argc, _TCHAR* argv[])
{
char c;
std::cout << "Please help!!!" << std::endl;
std::cin >> c;
mistake
return 0;
}
mistake above is not detected as a code change
What I've tried:
Uninstall reinstall Visual => same behaviour
Uninstall and reinstal other version of Visual => same behaviour
Tried with a very simple project to make sure that my real project and cmake chain is not responsible for this. This new very simple project is the main above
What other information I can provide :
Already tried the stuffs in Tools>Options> project and solutions > build and run where i set "on run when project are out of date" = "always build". => no change
If i update a header file referenced in my main file, the build process will go just fine. Of course I don't want to have to rememeber all the header files i need to modify to rebuild my project correctly. This no accetable solution.
I have installed no other tool/component that could explain this.
There were no visual or windows update at the same time that could be responsible for this.
This happens also on one of my colleague's a computer (but not all of them). I can see no common radix between him an I that could help the investigation
This happened next to a time shift in my country. Not sure the translation to english is ok but to be precise enough : time reference has been advanced from one hour.
Any help would be very appreciated because I've already spent several days investigating on this and rebuilding all my projects takes so many time it starts to make me crazy.
Ok, so I don't know neither what happened nore what is responsible for this problem but I have a workaround/Fix (not sure this is a fix because I can't locate the problem precisely) to propose.
I told this happened next to a time shift in my country and my recent discovery confirmed that.
What I did to fix my problem is the following :
Switched my time zone from local one to UTC, validate, and then switched it back to my local time zone again, validate again.
And then, it worked.
Strangest thing I have ever faced.
Definitely classified in my "WTF problems" section.
Really hope someday this will help someone.
I have several programs that I have created in vb.net visual studios 2010. I have been working on these programs for months with no problems. Recently I started having an issue where I can no longer access my temp directory while debugging within VS. I can't use My.Settings anymore because these use those temp files. This is the error I get:
Failed to save settings: An error occurred loading a configuration file: Could not find a part of the path 'C:\Users\USERNAME\AppData\Local\PROGNAME\PROGNAME.exe_Url_gty0snnfox5ji5xgprklljwb0e0mthek\1.0.0.0\nl3u0fw2.tmp'. (C:\Users\USERNAME\AppData\Local\PROGNAME\PROGNAME.exe_Url_gty0snnfox5ji5xgprklljwb0e0mthek\1.0.0.0\user.config)*
This file is there though.
I also get an error when trying to use my web services. I get this error:
Access to the temp directory is denied. Identity 'DOMAIN\Username' under which XmlSerializer is running does not have sufficient permission to access the temp directory. CodeDom will use the user account the process is using to do the compilation, so if the user doesn�t have access to system temp directory, you will not be able to compile. Use Path.GetTempPath() API to find out the temp directory location.*
I used the Path.GetTempPath() as the error says and I am trying to access: >"C:\Users\USERNAME\AppData\Local\Temp\"
I have tried going to these folders and making sure that I have the security set to allow everyone complete control. I believe it is a problem with VS not my program because I get the same problem on all of my programs, some of which I haven't opened in months. I did a repair on VS.
I can't think of what might have changed to cause this to stop working all of a sudden. I traveled to a customers facility where I had to change some network settings, but everything should be set back as it was now. My temporary security certificate expired, but I created a new one and now the certificate I am using to sign these applications is in my trusted root on certificate manager and looks to be valid. I should also mention that this is a clickonce deployment and the deployement works fine on my computer and others, it is only while debugging that I have these issues.
I have been running this down for weeks and spent countless hours looking for a solution and have come to a brick wall. Does anyone have any suggestions?
Thanks ahead of time for your help and time! Please let me know if I can clarify anything.
It turns out that the problem was coming from the fact that somehow one of the folders in the filepath to my user.config file got changed. Somehow a .vshost got thrown in on one of the folder names. I still have no idea how this happened and what caused this to happen, and I am not 100% sure that I have gotten to the real root of the problem, but for now, I am able to debug again. I changed the file name back to what it was supposed to be and the errors have stopped. Now lets just hope the file name doesn't get changed back again.
Problem Description:
Occassionally when debugging, I get the following error. I'm using visual studio 2010:
1>------ Build started: Project: projectName, Configuration: Debug Win32 ------
1>LINK : fatal error LNK1104: cannot open file 'C:\Projects\projectName\Debug\projectName.exe'
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
Note that projectName is the name of my project. The error occurs when I debug, make changes, and debug again (after doing all of that, the above error shows up instead of running the program a second time).
Steps to replicate:
Create a new empty c++ project, and add a file called "main.cpp" to the sources folder
Copy the following code into main.cpp:
int main(){
return 0;
}
Click the green debug arrow button, and note the successful run of the program. Ensure it is closed and that the debugging session is over. Open the process explorer and ensure the exe for the project is no longer running (if it is, wait until it closes).
Erase the contents of main.cpp and replace it with this code (or any other code that will compile properly which is different than the code used above):
#include<iostream>
int main(){
std::cout<<"hello\n";
return 0;
}
Click the green debug arrow button. Instead of running the program, the IDE will show the fatal LNK1104 error. You've now replicated the problem.
Any ideas on how to fix this?
Additional Details:
If I try to change the permissions or delete projectName.exe after the error has occured, an error popup shows up which says:
You need permission to perform this action
You require permission from the computer's administrator to make changes to this file
I am using windows 7.
The account I'm using is an admin account, but this issue also occurs exactly the same when I use a non-admin account.
For 2-3 minutes after the error occurs, I cannot rebuild or debug the project, but after approximately that amount of time, I am able to start at the beginning of the repro steps again.
UPDATE: BOUNTY
Anyone who can offer a solution that fixes the problem gets 100 rep :)
I've tried stopping all services, processes and applications that could be interfering with VC++ accessing the file, and the issue is still occuring. Also, running vc++ as an admin does not help.
This is most likely a bugfeature of the Windows Explorer.
Make sure that the .exe file is NOT selected/focused in the Windows explorer. On Vista i often get LNK1104-errors, when the executable file is selected in the Windows Explorer during linking.
If that does not help, check that no other program has "selected" the file.
EDIT:
This program can show you which process has locked your file (the pages contains some links to other "unlock" tools aswell)
I had this problem with a new program I was writing that seemed to compile once but gave your error at the end of compilation and on subsequent builds. My Antiviral program, BitDefender, had locked the exe file. My exe was in the list of viruses found. I turned off Bitdefender for 5 minutes, recompiled and the program was not locked when Bitdefender restarted or thereafter.
You can use Process Explorer to see if any process has a handle open to that file, even if the executable itself isn't running. Go to Find -> Find Handle or DLL... and type in projectName.exe, and it will give you a list of all processes that have it open.
My guess would be that something has a lock on the file. For whatever reason, VS cannot open the file to write the output of compilation. As SnOrfus suggests, make sure some sort of profiling or testing tools aren't open. I would also try to wait a few seconds between finishing an execution of the program (debug or otherwise) before attempting to rebuild. It's possible that you're building so fast that the debugger still has a lock on the file when VS attempts to access it.
I've never seen that happen when there wasn't a lock on the file. Do you have any profiling or testing tools that might still be holding on to it?
note: I wasn't able to repro that.
edit> Have you tried opening process explorer while the program is running (as opposed to task manager)? It'll show you if your exe is running in any other processes.
Have you checked for malware? I recently had a case where some malware that would bootstrap every process that ran on a machine, and task manager wasn't very informative.