My Software is writing to an ini file in c:\users...\documents and from time to time I get error reports from users where the WritePrivateProfileString call returns false and then GetLastError returns 2 (ERROR_FILE_NOT_FOUND).
I don't understand how this can happen and I wasn't able to reproduce it, since WritePrivateProfileString is supposed to create the file if it's missing.
If the directory didn't exist, the error would be ERROR_PATH_NOT_FOUND, if the file couldn't be created for permission reasons, it would be ERROR_ACCESS_DENIED.
So does anyone know why/when this function can produce this error? And how I can deal with it? As in: I rely on the file being created if necessary.
I think I may have found the answer myself.
The problem seems to occur when Windows Security -> Ransomware protection -> Controlled folder access is enabled and the application isn't white-listed.
ERROR_FILE_NOT_FOUND is a very confusing error message for this situation imho...
Related
I am working on a solo project where admin users will be able to manage Virtual Machines via a web application run on laravel 7. I am currently creating the creation controller which requires uploading large files (.ovas). I am trying to use streams (I think) in a store method.
Specifically, a view has a form with a standard file inclusion that sends the request to the controller. The form gets validated and then I try to move the file into storage as such:
$data = $this->validator($request);
Storage::put('files', fopen($data['file'], 'r+'));
Where $data['file'] is the uploaded file. I can see the file being uploaded locally (while monitoring hdd usage), but after it is sent, laravel returns the following error
fopen(/var/www/html/devel/ocl/storage/app/files): failed to open stream: Is a directory
The error seems pretty obvious, so I was curious and decided to return the fopen() call before storage to see if I could invoke the same error by changing the method to:
$data = $this->validator($request);
return var_dump(fopen($data['file'], 'r+'));
However, no error is invoked and I get resource(8) of type (stream) as expected (I think). The tmp resource disappears and no errors are thrown. I am a bit baffled on why this is occurring as I would assume that function call resolves before the storage. I feel like I'm missing something fundamental with PHP/laravel and cannot think of how to continue to explore the issue.
Why does the first call to fopen() seem to see $data['file'] as a path, but the second call to just fopen() work as intended? I am hoping the answer can help remedy the issue.
Thanks!
I have written a Firefox Extension using Web Extension APIs. It has passed the Preliminary review but the reviewer said that he cannot proceed with the full review cause when he installs it, he gets the following error -
"Unable to parse JSON data for extension storage"
Upon inspecting for quite sometime, I figured that Firefox creates a file called "storage.js" in the profile folder for each extension where it writes and reads from, all the local storage data for that particular extension. And if the extension tries to write to this file before this file is created, the error "Unable to write JSON data to extension storage" is thrown and if the extension code tries to read from this file before this file is created, the error "Unable to parse JSON data for extension storage" is thrown.
Now, my concern is how do I know for sure that the file has been created and that it can be written to or read from?
PS : This happens when the extension is just installed. For consequent sessions, this error wont come as that file is no longer missing.
This seems to be a bug in the current Firefox implementation, and your assessment is spot on:
The underlying ExtStorage module will always call read before get, set etc. even write and clear.
read will unconditionally try to access the underlying, extension specific storage file, that may not exist yet for freshly installed add-ons using the storage API for the first time.
This will therefore result in the logging of one such Unable to parse JSON data for extension storage message, no matter what you do with the storage API.
Therefore triggering the message cannot be avoided.
I suggest you do the following:
Contact the editors team, requesting they re-evaluate your add-on based on:
The message in question is really only a warning (when appearing after first access of the storage API by your addon).
Even when the message would be an actual error (the storage is corrupt), it would still not be your error, as the storage API implementation by mozilla needs to be more resilient then and there is nothing you can do anyway.
The message being issued on first regular use of the storage API, unrelated to what WebExtensions add-on uses that API and in what way, is a mozilla bug, and not something you caused or can fix yourself or at least work around.
Therefore denying a full review just because a mozilla bug erroneously logs a spurious message once without any other severe effects is... questionable.
File a bug about this so mozilla developers can address this issue. You'll wanna CC at least Bill McCloskey (:billm) since he wrote that code ;)
I am getting consistently a return value of 5 from RmGetList, any possible reasons?
I am following this tutorial: http://blogs.msdn.com/b/oldnewthing/archive/2012/02/17/10268840.aspx
My RmStartSession and RmRegstierResources both return 0 which means success. A note though, after RmStartSession the dwSession is always 0, and my szSessionKey stays a string in the form of 0ea790d06656a54f84645b5755f7b6d6 null terminated. Is this a problem?
My code is js-ctypes so I'm reluctant to share this in winapi but ill share it: https://github.com/Noitidart/_scratchpad/blob/master/_WinAPI-RstrtMgr.js#L293
Edit: I learned that dwSession of 0 is a valid. However I still can't figure out why I'm getting access denied on RmGetList, anyone any ideas?
I've learned that the restart manager doesn't support folders, and the error 5 is returned when you're trying to pass a folder:
https://blog.yaakov.online/failed-experiment-what-processes-have-a-lock-on-this-folder/
Update: here's some sample code of how to use the restart manager API:
https://github.com/Microsoft/msbuild/blob/master/src/Tasks/LockCheck.cs
RmGetList will return error 5 if any higher level thing like a file system fillter block the file
the driver filter denies access to file xxx from any process and function whether windows kernel or user code tries to access it
it does the same with restart manager , restart manger tries to access the file , the driver throws error 5 , the restart manager wont know what to do with it ,and rethrows it back to calling function ,so you'll get a access denied
if you are trying it for all files in windows volume, there will be much files with throwing error 5, including 3rd parity antivirus files or ms defender or ...
simply use a try catch and ignore them because even if you know what pid is locking them you couldn't do anything about it, other than watching
it also happens if you don't have even read access to the locked file ,in this case try fixing security permotions and trying again
My call to SMJobBless() is returning error 5 (kSMErrorToolNotValid), even though SMJobBlessUtil.py check doesn't find any problems. (It did initially, and I resolved them all)
SMJobBlessUtil checks a lot of stuff, including:
Code singing on app and tool, including checking designated requirements
info.plists refer to each other correctly
Label field in launchd.plist is correct
What else could cause it to fail?
OK, so it just turns out I was referring to my tool by the wrong name. So the "not valid" error can also mean "not found".
None of out programmers has changed anything to the code, but out of nothing now, when a user tries to login on the backend, we have this error:
Fatal error: Call to a member function children() on a non-object in
/home/r1tech/public_html/app/code/core/Mage/Admin/Model/User.php on
line 437
Any ideas why this is happening?
Not a real Magento problem.
Somehow the files got corrupted. I re-uploaded everything and now it works just fine.
Leaving this for the occasional googler with this issue:
We had this problem today, after we had tested different caching mechanisms for Magento. In the process, the file cache directory was somehow corrupted or otherwise made unusable. If you're not keen on reuploading the entire thing as Beto Frega suggests, you should be able to solve it by removing (or renaming) the var/cache (in the Magento webroot, not the server itself!!) directory and creating a new one, which you then obviously give write permissions to.
This solved the issue for us -- and incidentally also some performance issues in the backend, due to the sheer size of the old cache dir.