I would like my Browser Helper Object which is simply a .dll, to be able to read a text file. I have tried using a pointer to a FILE, as well as ifstream in("file name goes here"). Before implementing these two methods of reading files into the BHO, I tested them individually, and made sure each example dealt with similar data types and locations. Both of them worked without a problem, yet testing the BHO reveals that the file cant even be opened. I have searched google for an alternative method, and after exhausting all other options, I'm hoping that someone would be able to provide me with some guidance/resource. Anything is appreciated; I will keep trying to find a solution and will post what I can in the event that someone else may have the same problem.
Are you providing an absolute path to the file? If you're just using a relative path you may not be in the same working directory while running IE.
I think you might be a victim of the IE protected mode.
http://www.codeproject.com/KB/vista-security/PMSurvivalGuide.aspx
Under protected mode your addin might not have access to registry and file system as you might like.
Related
I've had trouble with this issue across many languages, most recently with C++.
The Issue Exemplified
Let's say we're working with C++ and have the following file structure for a project:
("Project" main folder with three [modules, data, etc] subfolders)
Now say:
Our maincode.cpp is in the Project folder
moduleA.cpp is in modules folder
data.txt is in data folder
moduleA.cpp wants to read data.txt
So the way I'd currently do it would be to assume maincode.cpp gets compiled & executed inside the Project folder, and so hardcode the path data/data.txt in moduleA.cpp to do the reading (say I used fstream fs("data/data.txt") to do so).
But what if the code was, for some reason, executed inside etc folder?
Is there a way around this?
The Questions
Is this a valid question? Or am I missing something with the wd (working directory) concept fundamentals?
Are there any methods for working around absolute paths so as to solve this issue in C++?
Are there any universal methods for doing the same with any language?
If there are no reasonable methods, how would you approach this issue?
Please leave a comment if I missed any important details with the problem's illustration!
At some point the program has to make an assumption where the file(s) are. Either by getting it from user input or a relative path with the presumed filename. As already said in the comments, C++ recently got std::filesystem added in C++17 which can help you making cross-platform code that interacts with the hosts' filesystem.
That being said, every program, big or small, has to make certain assumptions at some point, deleting or moving certain files is problematic for any program in case the program requires them to be at a certain location under a certain name. This is not solvable other than presenting the user with an error message etc.
As #Hatted Rooster said, it's not generally solvable for some arbitrary file without making some assumptions, however there are frameworks that allow you to "store" some files in the resources embedded into the executable (or otherwise). Those frameworks would usually allow your to handle such files in a opaque way, without the need to rely on a current working dir or relative paths.
For example, see the Qt Resource System.
Your program can deduce the path from argv[0] in the main call, if you know that it is always relative to your executable or you use an absolute path like "C:\myProgram\data\data.txt".
The second approach works in every language.
I am using visual studio to develop a windows form application in c++ to detect certain anomalies and log it.
The log file that I am intending to create will be of a common format such as .txt. I do not want users of the computer to modify this file that is I want only my program to modify it( I want users to read this file not modify it).
Is there any way to achieve this??
if you want to hide the content from other users then encrypt the file or use a binary format that only your program will be able to understand.
As long as the file resides on a publicly accessible area in the file system, then other users will be able to access it.
You can put the file in a specific user's Documents area, which might go some way to protecting the file from other users of that machine, but not from administrators.
You could even set the file attributes to "hidden" or something along those lines, to further make it hard for people to find it. But a complete access block is difficult (if not impossible).
After all this, you can also use NirMH's method to ensure that even if someone finds and attempts to read the file, then the encryption should make it difficult to crack it open. A binary format can still be read with a hex editor, if someone is really keen to read your file.
I have preferences file for my application in Qt.
Whenever I launch the application it loads the file & depending the contents creates the widgets accordingly. I have given some customisation option for the user. Now when my application is closed I am checking whether the preferences are changed. If yes then I am opening the preferences file again & then just adding everything again in it. I am not creating a temporary file, I am directly editing the file. Is this method an efficient one? or am I doing it wrong? because I found these threads:
1. What is the best way to edit the middle of an existing flat file?
http://qt-project.org/forums/viewthread/25924/
Should use I binary file? Currently I am using ASCII file.
Thanks.
UPDATE: In the stackoverflow link above the correct answer has
If you're stuck using flat, then you're stuck using the old fashioned
way of updating them
I meant to ask whether the method I am using is old fashioned & is there a better method used nowadays? & what does flat file mean?
Don't try to edit the file. Rewrite the whole thing
Rewrite by using a temporary file. i.e. write the current state of preferences into temp file. And then move/rename the file to your actual preference file after making sure the temp file has been written successfully. This helps in case there is a crash when you rewriting the file. If you rewrite it directly, you will be left with neither the old one nor a good new one. In case you do it through a temp file, then do it this way ensures that in case of a crash, you atleast have a good preferences file(though it contains the old preferences).
Text/Binary doesn't make much difference unless it's a really huge file. Text will help to hand edit it if required.
That's a perfectly fine way of doing it. Since you already seem to have all of the preferences loaded into memory and you have edited them there, you don't need to bother with a temporary file (unless you want to ensure safety if your program fails during writing). Just write all of the preferences back into the original file.
Whether you choose a binary file or text file is up to you. Preferences tend to be text files because they have the added benefit of being human readable with just a text editor, rather than some specialised software for viewing them. A binary file may, however, have slightly better performance due to simpler decoding.
I'm making a simple game with SFML 1.6 in C++. Of course, I have a lot of picture, level, and data files. Problem is, I don't want these files visible. Right now they're just plain picture files in a res/ subdirectory, and I want to either conceal them or encrypt them. Is it possible to put the raw data from the files into a resource file or something? Any solution is okay to me, I just don't want the files exposed to the user.
EDIT
Cross platform solutions best, but if they don't exist, that's okay, I'm working on windows. But I don't really want to use a library if it's not needed.
Most environments come with a resource compiler that converts images/icons/etc into string data and includes them in the source.
Another common technique is to copy them into the end of the final .exe as the last part of the build process. Then at run time, open the .exe as a file and read the data from some determined offset, see Embedding a filesystem in an executable?
The ideal way for this is to make your own archive format, which would contain all of your files' data along with some extra info needed to split files distinctly within it.
I want to make sure no other process changes the contents of a particular folder. I'd like to stop other processes from creating, deleting, or modifying files within a folder. Further, I'd like this restriction to nest down into subfolders.
I can get close to what I want by enumerating the contents of the folder and calling CreateFile on each file. This has problems in that it doesn't stop new files from being created and requires I acquire lots of handles.
Is there an easier way to get what I want?
Update: Addressing some comments, what I want to do is to prevent modification while my program is running. It's OK if the file get modified between runs.
In terms of ACLS, the app has read access to all files within the folder.
ACLs would be the best way to go but if you can't get that to work for whatever reason (you're fairly thin on the details) then use a file system filter driver. Note that this isn't very straightforward. Not rocket science either, but you have to be extra careful with driver development.
http://www.microsoft.com/whdc/driver/filterdrv/default.mspx