I want to refer a file for some information like the last time the user had used the program and etc. But I can't just use textfiles because the user may edit it, or even worse delete it.
So is there a way to refer an external file that the user cannot access by clicking, outside the program? Better yet if the file is invisible like a .ini file or something.
This is possible right?
And also what if I want more protection, what is the best way to encrypt that file?
My bad I should have googled first heh. SetFileAttributes can set a file to become invisible. But is there a non os-specific method? Why aren't there such cool functions in other os other than windows?
Possibly in the std::filesystem class.Quote:
But is there a non os-specific method?
There are, you just haven't stumbled across them yet. Do you realize that on Unix/Linux you can "hide" a file by simply starting the name with a dot(.)?Quote:
Why aren't there such cool functions in other os other than windows?
By the way on Windows to "hide" a file I believe you need to be using something other than the "FAT" based filesystem since "FAT" doesn't support most(any?) file attributes, also it appears that you need at least Windows XP for that function.
Oh lord jim how the hell do you know so much stuff! But there's isn't something like the <windows.h> for other os right?Quote:
Originally Posted by jimblumberg
I can't quite tell whether you're expecting there to be a corresponding header, but of course there is. There's <unistd.h> for a start, which is standard POSIX (unix-like things), as well as a bunch of system-specific things that you would find in sys/ as well. If you have access to a *nix machine, you can doQuote:
Originally Posted by Nwb
to see all the headers you have at your disposal. (You should see all the standard headers, of course, plus the system-specific ones here, plus some directories that have more.)Code:ls /usr/include
I sincerely hope not. IMO, windows.h is an abomination since it is from the "throw in every thing, including the kitchen sink" mentality of programming. Realize that #including that header can cause almost every windows API header to be #included. On other operating systems they prefer you to only #include necessary includes, not every #include under the sun. Remember that #including unnecessary #include files can cause increases in compile times.Quote:
But there's isn't something like the <windows.h> for other os right?
That is a good point; I have gotten into the habit of looking up the actual header the functions I'm using are in, so I don't think I've done <windows.h> in a long time.Quote:
Originally Posted by jimblumberg
And to go back a bit to one of the original questions; the prefix-with-a-dot method hides a file from "normal" directory listings (although there is a flag to show them, just as "hidden" files can be seen via some clicking), but in general on a *nix system a program will have the same filesystem privileges as the person who runs the program, so if your program wants to be able to edit a file the user has to also be able to edit that file. Making the structure of the file opaque can't prevent a user from corrupting the file, but at least it's possible that the edit they make will just corrupt the file rather than change it to something valid-but-different.
But that also means that you can do a lot of stuff in windows that you cannot in other os right? From what you're saying, instead of including the headerfile itself, would it make sense to pick only the thing you're using? Like suppose if I'm using only sleep or GetConsoleCursorPosition, is it possible to only pick out those things required for these or is that too complicated for a regular joe like me to do?Quote:
Originally Posted by jimblumberg
Why would you think that? The guy who knows next-to-nothing? You really need to embrace your ignorance, buddy.Quote:
Why aren't there such cool functions in other os other than windows?
Are you dyslexic or something? You need to read (and think) more carefully. He didn't say anything even remotely like that.Quote:
But that also means that you can do a lot of stuff in windows that you cannot in other os right?
Consider encryption.
It might be a pain because you have to learn an encryption algorithm, and your program has to decrypt the file (in RAM) before using the contents, but the contents are at least somewhat protected.
You don't know what I'm asking, I was asking about <windows.h> please don't get so excited. You're not gaining anything from making that post, I won't look at anything differently not even you (and you should hope so from the way you posted that) so really there's no point in wasting your own energy.Quote:
Originally Posted by john.c
But these other people are trying to help me, they are doing something useful and good.
Yea any suggestions? At this point I'm just asking out of curiosity.Quote:
Originally Posted by whiteflags
Well, encryption is a rather big topic and using it in a secure way can be hard. I'm going to assume that whatever you want to hide is fairly nonserious and you just want to protect a file from end-user tampering. In which case, opening a file to a bunch of jibberish might be enough.
The Vigenere cipher is pretty much everyone's first algorithm, and it certainly hides plaintext. It will teach you the most basic thing about ciphering and not much else. There are no keys so it isn't very secure. People also might look at xor ciphers or an xor cipher with a one time pad for something nonserious that still needs to be hidden.
To do a very good job encrypting what you need is a known algorithm (here's one) and a decent way to generate an encryption key. For nonserious tasks, I think it's okay just to be clever with keys, like using a hash of something or maybe a psedo-random number generator (as long as you can seed the prng again).
This is also true when dealing with the SetFileAttributes(), this function is not setting "filesystem privileges" it can just set several distinct "attributes". Also this function is defined in the fileapi.h header file, which is one of the many includes that windows.h #includes.Quote:
And to go back a bit to one of the original questions; the prefix-with-a-dot method hides a file from "normal" directory listings (although there is a flag to show them, just as "hidden" files can be seen via some clicking), but in general on a *nix system a program will have the same filesystem privileges as the person who runs the program, so if your program wants to be able to edit a file the user has to also be able to edit that file. Making the structure of the file opaque can't prevent a user from corrupting the file, but at least it's possible that the edit they make will just corrupt the file rather than change it to something valid-but-different.
Err... as much as I'd prefer for john.c to be a bit nicer when dealing with such remarks, the thing is that you do need to be more prudent before making such statements. You weren't just asking about <windows.h>, you also implied that:Quote:
Originally Posted by Nwb
- There are no "such cool functions in other os other than windows". (a.k.a. operating systems other than Windows suck)
- "there's isn't something like the <windows.h> for other os" (yes, you were asking, but you were asking for confirmation)
- "you can do a lot of stuff in windows that you cannot in other os" (again, asking for confirmation)
when you make such statements, you can expect to get slammed if you are wrong. So either do your research and make sure that you are right, or if you're not sure, ask. You could have written "oh wow, <windows.h> has such cool functions! What are the equivalent in <specify other OS here>?", "do other OS have something like <windows.h>?", and "does this mean you can do a lot of stuff in windows that you cannot in other os?" Sure, people might disagree with you about <windows.h> being cool, or they might chide you for misunderstanding what was written, but since you're asking rather than insinuating that other operating systems suck, you're far more likely to get away with it.
"The most important single aspect of software development is to be clear about what you are trying to build." -- Bjarne Stroustrup, the designer and original implementer of C++, but these words apply to C too. So there's the thing about whether you are trying to create a log, or whether it is some kind of updatable list of records, and then just how important is it to avoid tampering, or to detect tampering, or is it a showstopper if you cannot prevent the deletion of the information, etc.Quote:
Originally Posted by Nwb
I tend to be in favour of using SQLite as an application file format by default (the SQLite docs cite "improved performance, reduced cost and complexity, and improved reliability", basically because you're deciding on the relational database schema rather than actually coming up with the nitty gritty of a file format and parsing it, while keeping to a single database file), and that would avoid casual tampering (since the user would need to use a program to edit the SQLite database), or at least detect it (because the SQLite database would be corrupted if the user attempted to modify it without treating it as a SQLite database). But this is only my suggestion by default; without knowing what in detail what you're after, things like encryption may be overkill, or may be insufficient (how are you going to hide the private key?). It may turn out that you need a client/server model such that the log or whatever is stored append-only on a server to which the user has no access.
EDIT:
No, a Vigenere cipher still uses a key. What makes it insecure is that the key material is repeated in a rather predictable way.Quote:
Originally Posted by whiteflags
I'll keep that in mind laserlight. I just wanted to have a file that would contain information like performances and last played, but I didn't want the user messing with it just in case (since it is a .txt after all).
I think I'm going to caesar encrypt and set the text file to invisible just in case. That makes sense?
I thought about putting the file in some other directory but I guess that's not required.