0

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();
}
Ben
  • 427
  • 5
  • 17
  • Unfortunately, because I can't share the .sln files, all I can do is share the (working) code above, which isn't really that helpful. :( The solutions were created on the same PC, using the same wizard and the same steps. I've not been into the project settings in either case, but obviously there IS a difference somewhere. Perhaps its just going to be a manual exercise... – Ben Oct 05 '18 at 08:42
  • Do distinguish between "access violation" and "access denied". Only the latter seems plausible, error code 5. These look like directories, not files. Consider that the target directory already exists so can't be overwritten by MoveFile(). – Hans Passant Oct 05 '18 at 08:43
  • Sorry, you're correct Hans, access denied is the error. Code 5. I'll correct the post. – Ben Oct 05 '18 at 08:47
  • I suspect the difference is in the actual paths, or do you have the same hardcoded paths in the non-working solution? When the same, check under which credentials both executables run. When different, well, check the permissions of the files and directories. – CodeCaster Oct 05 '18 at 08:50
  • The paths are hard coded. Literally the code you see above in both Solutions. The .exe files have the same credentials when looking in Explorer->Properties->Security. I'm also the owner with W/R access to the folders above. This is somewhat implicit given that one Solution works and the other doesn't. I did wonder if there was a way to check what VS2013 is actually running the app as or if it just uses the current user credentials (assumed this is the case). – Ben Oct 05 '18 at 08:58

1 Answers1

0

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.

Ben
  • 427
  • 5
  • 17