I am using the rename function with RTEMS to attempt to rename files. I am setting up a correct error handling and reporting system when i discovered that RTEMS does not seem to be conforming to its own errno reporting guide.
So the function in failure will always return -1. The current example is in a directory </D\> where i have the following:
</D\LALALA>
</D\LALALA_2>
</D\OTHER_DIRECTORY>
I call rename("LALALA_1", "LALALA_2") which works correctly and the folder is renamed. So i know the function works. If i call rename("LALALA", "LALALA_2"), it fails returning -1... which is great, but instead of EEXIST i get errno == -1.
So this looks to be a bug with the RTEMS implementation.
https://lists.rtems.org/pipermail/bugs/2014-January/004755.html
It is not likely that it will ever be fixed.
Related
See below for the following code, and below that, the error that follows.
std::string source = "C:\\Users\\cambarchian\\Documents\\tested";
std::string destination = "C:\\Users\\cambarchian\\Documents\\tester";
std::filesystem::path sourcepath = source;
std::filesystem::path destpath = destination;
std::filesystem::copy_options::update_existing;
std::filesystem::copy(sourcepath, destpath);
terminate called after throwing an instance of 'std::filesystem::__cxx11::filesystem_error'
what(): filesystem error: cannot copy: File exists [C:\Users\cambarchian\Documents\tested] [C:\Users\cambarchian\Documents\tester]
Tried to use filesystem::copy, along with trying different paths. No luck with anything. Not too much I can write here as the problem is listed above, could be a simple formatting issue. That being said, it worked on my home computer using visual studio 2022, however using VS Code with gcc 11.2 gives me this issue.
Using:
filesystem::copy_file(oldPath, newPath, filesystem::copy_options::overwrite_existing);
The overloads of std::filesystem::copy are documented. You're using the first overload, but want the second:
void copy(from, to) which is equivalent to [overload 2, below] using copy_options::none
void copy(from, to, options)
Writing the statement std::filesystem::copy_options::update_existing; before calling copy doesn't achieve anything at all, whereas passing the option to the correct overload like
std::filesystem::copy(sourcepath, destpath,
std::filesystem::copy_options::update_existing);
should do what you want.
... it worked on my home computer using visual studio 2022 ...
you don't say whether the destination file existed in that case, which is the first thing you should check.
I put the copy_options within the copy function but it didn't work so I started moving it around, I probably should have mentioned that.
Randomly permuting your code isn't a good way of generating clean examples for others to help with.
In the rare event that hacking away at something does fix it, I strongly recommend pausing to figure out why. When you've hacked away at something and it still doesn't work, by all means leave comments to remind yourself what you tried, but the code itself should still be in a good state.
Still doesn't work when I write std::filesystem::copy(sourcepath, destpath, std::filesystem::copy_options::recursive)
Well, that's a different option, isn't it? Were you randomly permuting which copy_options you selected as well?
Trying recursive and update_existing yields the same issue.
The documentation says
The behavior is undefined if there is more than one option in any of the copy_options option group present in options (even in the copy_file group).
so you shouldn't be setting both anyway. There's no benefit to recursively copying a single file, but there may be a benefit to updating or overwriting one. If the destination already exists. Which, according to your error, it does.
Since you do have an error explicitly saying "File exists", you should certainly look at the "options controlling copy_file() when the file already exists" section of the table here.
Visual Studio 2022 fixed the problem
nRetVal = context.InitFromXmlFile(SAMPLE_XML_PATH, &errors);
Above is the function which results in the errors. Actually, SAMPLE_XML_PATH is xml file's path. I tried relative path and absolute path. But the error still pumps out. The return value(nRetVal) of this function is supposed to be 0 here. But the return value is 65537. This function is to read kinect information through XBOX360.
Blow is the error message.
Failed: The parameter is incorrect.
[80070057] (m_pDmo -> AllocateStreamingResources())
m_pReader->Start():Error!
But Niviewer samples all run very well.
Is there any engineer who has bumped into this problem before? I have been struggling for this for a whole day.
Note: This program run pretty well yesterday. But the error pumps out today with similar program. (The difference between them can be ignored because I've already test it.)
I will appreciate your any answers.
When I initialize the kinectInterface handler, I use pointer to "new" a memory and commit operation on the memory.
The bad thing is the handler has never been closed if main process exit.
The Solution is put the pointer into smart pointer like "Ptr" would solve the problem.
I’m using the following code to delete an empty folder on Linux:
bool removeFolder (const QString& path)
{
QDir dir(path);
assert(dir.exists());
return dir.rmdir(".");
}
For some reason it sometimes returns false (for specific folders, but those folders don’t seem to be wrong in any way). If I subsequently use ::rmdir from <unistd.h> to remove the same folder, it succeeds.
How can I tell why QDir::rmdir is failing?
This never happened on Windows so far, QDir::rmdir just works.
Confirming: works on windown, fails on linux.
Reading the "rmdir" doc in <unistd>, here https://pubs.opengroup.org/onlinepubs/007904875/functions/rmdir.html, it says there that "If the path argument refers to a path whose final component is either dot or dot-dot, rmdir() shall fail." So what's probably happening is that QDir::rmdir() is calling the unistd rmdir() function in linux, and this one fails with ".".
I tried to just use the full absolute path ( QDir::rmdir(absolutePath) ) and it worked; however, i see basically no point in using QDir::rmdir() over unistd's rmdir(), so i''ll stick w/ the unistd rmdir() from now on.
note: QDir::removeRecursively() is a different story: it seems to work okay, and it's way more convenient than going through opendir() and then successive readdir()'s (or the nftw(...FTW_DEPTH...) thingie).
I had the same problem but on Windows, I could not delete an empty directory with QDir().rmdir(path);. This happened on some older hard drive so may be the ancient file system was to blame. But I found a hack:
QFile(path).setPermissions(QFile::WriteOther); // this works even for dirs
bool success = QDir().rmdir(path);
Of course, you should revert the permissions back to original values if the deletion was unsuccessful anyway, but that's a different story.
Try to use this one:
dir.rmdir(dir.absolutePath())
So i have a bit of code that uses Dos Commands to try to rename a folder. So
system("rename C:\\Users\\me\\SecondDir NewDir);
So this tries to rename SecondDir to NewDir. There is already a folder at that location called NewDir so it should fail. And it does. Im then using GetLastError to get the error code returned to ensure the problem is what i expect it to be. But it only ever returns ERROR_NO_MORE_FILES. Which isnt the error i should be getting, which is ERROR_ALREADY_EXISTS. Im assuming this is something to do with using the system command?
EDIT: I just checked and i even get ERROR_NO_MORE_FILES returned when a command is successful.
GetLastError will not return a meaningful value except in the circumstances where it is documented to do so. This is not one of them - the values you are getting are irrelevant and intended for someone else.
To rename a file from C you should use the C runtime rename function not use system to invoke a rename utility.
GetLastError is only meaningful immediately after calling a Win32 function which is documented to set the thread Last Error using SetLastError. The C equivalent is errno, which applies to C functions.
The rename function returns -1 on failure and sets errno.
E.g.: http://msdn.microsoft.com/en-us/library/zw5t957f(v=VS.80).aspx
I'm calling lt_dlopen and getting a generic file not found error (translated errno text). How can I get more information about what is actually failing, as the file is definitely there.
This is a C++ program loading a C++ library. Otherwhere in the same program I use the same command to open other libraries without a problem, thus I fear it might be something specific to this library. I've used ldd and all those dependencies of the library are met.
I stumbled across something that kind of works:
export LD_DEBUG=all
And then proceed to sift throught the extreme mass of output. In this case I found a "lookup error" and one of the symbols could not be resolved. I'm not sure why, but that is perhaps not relevant to this question.
Recompile libtool with "-DLT_DEBUG_LOADERS" in $CFLAGS. Adjust LD_LIBRARY_PATH so that your program will find this debug libltdl.so instead of the system one. That debug version of ltdl will print explicit errors for each loader's attempt to open the target with much less verbosity than LD_DEBUG=all.
From http://www.delorie.com/gnu/docs/libtool/libtool_46.html :
Function: lt_dlhandle lt_dlopen (const char *filename)
[...] If lt_dlopen fails for any reason, it returns NULL.
Function: const char * lt_dlerror (void)
Return a human readable string describing the most recent error that
occurred from any of libltdl's functions. Return NULL if no errors
have occurred since initialization or since it was last called.