PDA

View Full Version : win32 alternative for tmpfs


bisserke
05-23-2005, 11:56 PM
Hi all,

I know that the Unix Socket faq isn't really the place to ask but hey, i can try can't I? ^^

I got an assignment to create something like "mount none -t tmpfs /mnt/usertemp" on a win32 platform.

The problem is that it is maintenance that has to be performed on a piece of old code that has to be made multiuser. It exist of a series of independant executables that spawn each other and pass their data through simple textfiles.

Since my time window is pretty narrow and the code is nicely undocumented I'm trying really hard not to make too many changes. (Hey, what else to expect from code written over 15 years ago and later ported to 32-bit)
So I'd like to create a solution like the tmpfs because then I can create a "ramdisk" for every user and let the executables read/write/create their files in that directory without having to track down every file operation that occurs.

I can not use the ramdisk driver from wintendo itself because that stuff needs a reboot to work (who came up with this ?!?!?) and i can hardly let the server reboot itself for every user that logs on.

So if anybody has some pointers, hints,... I'd be very thankful because I've looked everywhere and can't find a solution. You can say I'm in the dark here.

thanks in advance,

Wouter Moors

i3839
05-24-2005, 01:40 PM
Using real files shouldn't be that slow, as it should be cached and buffered. Also, if it was fast enough 15 years ago, then any slowdown caused by the disk usage is dwarved by the hardware speedup anyway. So is it really too slow when you let it use the harddisk?

If it is too slow, can't you adjust it quickly to use FIFO's/pipes instead of real files? If it doesn't seek anywhere then it should be somewhat safe to just adjust all file open calls.

bisserke
05-24-2005, 03:01 PM
It is far from slow.
Some of these modules create scriptfiles that are parsed/run by other executables. Until now these scripts were unprotected and got frequently hacked by their service engineers which sometimes resulted in physical damage to the systems.
Now that company is fed up with it and no longer wants physical scripts to be created. Hence the Ramdisk assignment.

Problem is the time i've got to solve it. This piece of software is too complex to grasp in such a short while. (And it's on a need-to-know basis, meaning very little help from them) I don't know which files are critical and need to be included in the "usersession" that's why the tmpfs solution is ideal. Then I only need to alter the path.

But I've been playing around with FileMappings and I got so far that if I only could attach a win32 HANDLE to a FILE pointer I only need to change the fopen/fclose with my_fopen/my_fclose and I wuold be set. But guess what,...
I can't find a way to do that. I hate Bill !!!

anyway, thx for the reply

i3839
05-24-2005, 03:36 PM
Uhh, perhaps I'm dumb, but the script that were created could be just edited by "hackers", making the system insecure? Is that correct? So the solution to that is to not use files?? What stops them from replacing those executables with their own program? Slightly more work than making a script, but that doesn't mean it's more secure... Windows has no file permission stuff, right? But it does have ACL's as far as I know, can't you use that to protect the directory in which the scripts are created? If you can't even secure the files on the server, then why bother "fixing" *cough* it in one place while the whole system is insecure?

If the program/modules created scripts in the /tmp dir where everyone has access to, then just fix that instead. If it's the more fundamental problem of a totally whacky security, then don't even bother I'd say. Your job is to fix problems, in a good way, not to just do what the managements says it thinks is best, no matter how crazy.

bisserke
05-24-2005, 04:13 PM
Up until now the software ran on the laptops of the Field Service Engineers. They understood the scriptlanguage used and if they needed a quick hack, they altered the scripts. It's not like it ran on a server and it got hacked by script kiddies.
They are busy with new systems and new service software and therefore outsourced the maintenance to my company. Thing is, since it is a temporary solution they dont want to spend mucho money. So i got the just the time for a quick and dirty solution that has been designed by their system architects.

So I can shout/cry/'laugh insanely' as much as I want but that wont change a thing.

i3839
05-24-2005, 09:35 PM
If that's all then just XOR the out- and input with some fixed value and be done with it.