Re: [osf_alums] Relaying file ops to userland

[Michael O'Donnell]

>The problems with using a named pipe are:
[...etc...]

Right.  FYI, I'm developing some support infrastructure
that works in conjunction with certain apps that won't even
be aware that they're being "helped", so it's a requirement
that existing file-access behaviors be unchanged.

Thanks to all for the tips.  And Happy New Year, too.

___
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss

Re: Relaying file ops to userland

[Roger H. Goun]

On Tue, Dec 24, 2002 at 12:05:46PM -0500, you wrote:
> It seems that I recall several times in the past
> that I've stumbled across packages that allow you to
> rig your system such that various file operations
> are relayed to code in userland rather than (or in
> addition to) being handled by the kernel.  It seems
> that I recall one that (with minimal effort) provided
> the ability to create a device node that could be
> "owned" by an arbitrary userland process and I
> may have also seen some trick that allowed you to
> intercept arbitrary file ops on arbitrary files.
> 
> Assuming that I'm not just suffering some sort of
> False Memory Syndrome here, can somebody remind me
> where I might have seen these?

FAM?

http://oss.sgi.com/projects/fam/

-- 
Roger H. Goun  Brentwood Country Animal Hospital, P.C.
Chief Kennel Officer   Exeter, New Hampshire, USA
___
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss

Re: Relaying file ops to userland

[Michael O'Donnell]

I wrote:
> packages that allow you to rig your system such that various
> file operations are relayed to code in userland

...and thought some of y'all might find this related package
intriguing, though it isn't what I'm looking for:


>NAME
> dnotify - Execute a command when the contents of a directory change
>
>SYNOPSIS
> dnotify [OPTION]...  DIRECTORY...  [-e COMMAND...]
>
>DESCRIPTION
> This manual page document describes the dnotify command.
>
> The dnotify program executes COMMAND every time the contents of any
> of the specified directories change.  If a command is not specified,
> `echo {}' is assumed.
>
> What is considered a change is determined by the `--access', `--modify',
> `--create', `--delete', `--rename' and `--attrib' options (see below).
> These options may be combined.  If none of them are specified, create
> and delete are assumed.
>
> The string `{}' in the command specification is replaced by the name
> of the directory that was updated.
   .
   .
   .
   .


___
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss

Relaying file ops to userland

[Michael O'Donnell]

It seems that I recall several times in the past
that I've stumbled across packages that allow you to
rig your system such that various file operations
are relayed to code in userland rather than (or in
addition to) being handled by the kernel.  It seems
that I recall one that (with minimal effort) provided
the ability to create a device node that could be
"owned" by an arbitrary userland process and I
may have also seen some trick that allowed you to
intercept arbitrary file ops on arbitrary files.

Assuming that I'm not just suffering some sort of
False Memory Syndrome here, can somebody remind me
where I might have seen these?

BTW, a named pipe might at first seem to be a solution
until you remember that "real" files aren't FIFO...

___
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss