no*********@gmail.com wrote:
Say I'm writting a program. In this program for some reason I need to
store data somewere were I will be able to access it again. I don't
want to store it in a file because then it could be deleted by another
program or user. So, is there anyway to save data onto a computer so
that it will not apear as a file (actually idealy not apear as anything
at all), but will not get overwritten by any other program or file. If
this is OS spacific tell me because the more I think about it the more
it seems like it would be. Let me give an example of what I am looking
for:
/* getfmemloc() doesn't really exist */
/* putfmemloc() doesn't really exist */
getfmemloc(fmemloc); /* This would get data from the hard disk */
putfmemloc(fmemloc, data); /* This would put data to the hard disk at
that spot */
What is "femloc"? An inode? An int? Something else? This value is
key to your question. Even if you can actually get at the persistent
storage in some reasonable way, your approach will be tied to a specific
implementation of a filesystem. That is, there is no universal value
you can use for this argument that will translate into "a place on the
disk".
Anyway, this is security by obscurity which has very limited value.
Is there anyway to do that (put data on to the hard disk and read it
off without using files and without having to worry about other
programs overwritting it)?
Most operating systems offer resources like disk space in a highly
abstract way.
This is easily solved with a combination of file locking or memory
mapping (and perhaps encryption).
This is why some operating systems have high-level abstractions of
encrypted file systems that look and taste just like ordinary resources
that things like open() can get a handle on, even though they might be
doing some magic under the covers.
Another option is to do what databases did in the old days when they
could neither trust the filesystem or the other processes present on a
machine: build your own abstract filesystem out of big files. Grab some
chunks of disk as regular files (perhaps a linked-list of chunks so you
can dynamically grow and shrink as needed) and write your data to those
file(s) in some clever manner. You can obfuscate or munge that data how
you like. Judicious use of hashes and such will let you know if the
data is not to be trusted because it was changed outside of normal
processing.
Locking and file protection is still an OS abstraction, and you have to
trust that other process honour any ACLs (if present) you may have on
those files.
A related option is a small embedded database that you persist
serialized data to. Row locking is pretty robust, and most people will
never know your app has a little config file and database directory
squirrelled away.
