Re: Imaginary File Path
Re: Imaginary File Path
- Subject: Re: Imaginary File Path
- From: John Stiles <email@hidden>
- Date: Fri, 07 Dec 2007 08:50:08 -0800
There's a built-in RAM disk you can leverage for this sort of thing,
actually. I've used it in internal tools. It should work for you. I
wouldn't rely on it in a shipping app, though, because if one of your
tools dies somewhere along the way, you've left a big honking RAM disk
open on the user's system, chewing up resources. Also, it involves
shelling out to a bunch of external processes and parsing their output,
which always gives me the heebie-jeebies for a shipping app.
Other than that, like James says, pipes are good, and shared memory
would be another way to go.
When I was creating RAM disks, I was actually working in Perl, but
here's how you do it. This allocates an ~2GB RAM disk (adjust the
'4600000' value to change the disk size):
File::Path::mkpath( "$tempPath/RAMDisk" );
$ramDiskA = `hdiutil attach ram://4600000 -nomount`;
$ramDiskA =~ s|\s||g; # for some reason hdiutil returns a bunch
of spaces
system( "newfs_hfs \"$ramDiskA\"" );
system( "mount_hfs \"$ramDiskA\" \"$tempPath/RAMDisk\"" );
and this frees it:
$ramDiskA =~ s|^/dev/||;
`umount \"$tempPath/RAMDisk"`;
`hdiutil eject \"$ramDiskA\"`;
As I was saying before, neglecting to free the RAM disk is the
equivalent of spawning a new process on the user's computer, mallocing
2GB of RAM with it, and then never letting that process quit.
James Bucanek wrote:
John Goodman <mailto:email@hidden> wrote (Friday, December 7,
2007 7:35 AM -0500):
What I'd like to do instead, is to find a way to present my data as if
it were a file, without actually saving the data to disk. If I have
the data in memory, I'd like to be able to persuade the command line
tool that the file is "really" on the disk, by giving it an
"imaginary" file path.
You'll have to involve the file system. By definition, a "path" is a
name in a filesystem. To access the data associated with that path
you'll have to create an entity in the filesystem or the filesystem
simply won't know what your C++ tool is talking about.
Ideally, I could even stream the data to the tool, as long as the tool
thought it was working with a file.
The only simple choices that I can think of are a pipe or a socket,
both of which would require that the C++ tool read the data in the
file sequentially. To use a pipe your C++ would have to read the data
from stdin, for a socket your first process would create a UNIX domain
socket using bind (the socket will appear in the filesystem as a
socket file), then pass the path of the socket to the tool.
If the tool needs to randomly access the data in the file, things will
get considerably more complicated. You might experiment with mmap(),
although I doubt this will help much because ultimately the data will
still end up on the disk.
The only other solution that leaps to mind is something like FUSE
where you could create a virtual filesystem that presented your data
as a file. But that's like renting a crane to take out the garbage.
Or, just find yourself a RAM disk driver and write the data to a file
on the RAM disk.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden