Determining file name with /proc/pid/fd/#?

  • Permalink
  • submit to reddit
  • Email
  • Follow


Is there a way to determine the name of an open file?
I'm tired of not being able to determine if there is
a file open for writing that has been deleted.  If I
can get the  files each process has open I can check
if it exists and report back if it doesn't.

Just FYI, lsof does not show open files that are deleted.

TIA,

Roger Books

0
Reply roger.books (4) 9/19/2005 8:42:54 PM

See related articles to this posting

"roger.books@gmail.com" <roger.books@gmail.com> writes:

>Is there a way to determine the name of an open file?
>I'm tired of not being able to determine if there is
>a file open for writing that has been deleted.  If I
>can get the  files each process has open I can check
>if it exists and report back if it doesn't.

>Just FYI, lsof does not show open files that are deleted.

Yes, lsof DOES show open files that have been unlinked.
They can readily be identified by directing lsof to show
link count with the +L option.  Unlinked open files have
a link count of zero.

Because there is no DNLC information for unlinked files,
the identification lsof displays for them is basic --
device number, node number, and mounted-on directory and
mounted-on device paths.

Vic Abell, lsof author
0
Reply abe 9/19/2005 6:35:31 PM

"roger.books@gmail.com" <roger.books@gmail.com> writes:

>Is there a way to determine the name of an open file?
>I'm tired of not being able to determine if there is
>a file open for writing that has been deleted.  If I
>can get the  files each process has open I can check
>if it exists and report back if it doesn't.

In S10 look at /proc/<pid>/path

If it's deleted, it has no name so none can be reported.

If you want to find open, yet deleted files and the processes
keeping them open:

	find /proc/*/fd -type f -links 0

Casper
-- 
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
0
Reply Casper 9/20/2005 8:56:28 AM

Casper H.S. Dik wrote:
> "roger.books@gmail.com" <roger.books@gmail.com> writes:
>
> >Is there a way to determine the name of an open file?
> >I'm tired of not being able to determine if there is
> >a file open for writing that has been deleted.  If I
> >can get the  files each process has open I can check
> >if it exists and report back if it doesn't.
>
> In S10 look at /proc/<pid>/path
>
> If it's deleted, it has no name so none can be reported.
>
> If you want to find open, yet deleted files and the processes
> keeping them open:
>
> 	find /proc/*/fd -type f -links 0
>
> Casper

Be wary of /proc/<pid>/path.  It depends on a path,
stored in the vnode, that is not carefully maintained.
Lsof uses it with great caution, checking it via stat(2)
before displaying it.

Vic Abell, lsof author

0
Reply abe 9/20/2005 1:27:13 PM

abe@purdue.edu writes:

>Be wary of /proc/<pid>/path.  It depends on a path,
>stored in the vnode, that is not carefully maintained.
>Lsof uses it with great caution, checking it via stat(2)
>before displaying it.

Are you sure it returns an incorrect value rather than none?

Casper
0
Reply Casper 9/20/2005 2:16:11 PM

Casper H.S. Dik <Casper.Dik@Sun.COM> writes:

>abe@purdue.edu writes:

>>Be wary of /proc/<pid>/path.  It depends on a path,
>>stored in the vnode, that is not carefully maintained.
>>Lsof uses it with great caution, checking it via stat(2)
>>before displaying it.

>Are you sure it returns an incorrect value rather than none?

>Casper

The vnode's v_path pointer is still set for unlinked open
files to te address of a kernel string that contains the
path under which the file was opened.  I just double-checked
that with dbx on a Solaris 10 Amd64 generic kernel.

The v_path pointer is also incorrect for files that have not
been unlinked when the paths under which they have been opened
have been changed -- i.e, with mv(1) or rename(2) has been
applied.  This is true for the three Solaris 10 architectures
-- Amd64, sun4u and i86pc -- where I have tested lsof.

Is there a patch that fixes either or both problems?

Vic Abell, lsof author
0
Reply abe 9/20/2005 2:18:57 PM

Eric.Schrock@sun.no.spam.com (Eric Schrock) writes:

>In article <abe.1127243937@quest.cc.purdue.edu>, Victor A Abell wrote:
>>
>>The vnode's v_path pointer is still set for unlinked open
>>files to the address of a kernel string that contains the
>>path under which the file was opened.  I just double-checked
>>that with dbx on a Solaris 10 Amd64 generic kernel.
>>
>>The v_path pointer is also incorrect for files that have not
>>been unlinked when the paths under which they have been opened
>>have been changed -- i.e, with mv(1) or rename(2) has been
>>applied.  This is true for the three Solaris 10 architectures
>>-- Amd64, sun4u and i86pc -- where I have tested lsof.
>>
>>Is there a patch that fixes either or both problems?

>The above "problems" are both intrinsic to the design of v_path.  The
>path information was designed to aid in observability.  It never has had
>any guarantee associated with it that it is currently correct, only that
>it was correct at one point in time.  To do otherwise is to solve an
>essentially unsolvable problem (thanks to hard links) and require a huge
>amount of effort (requiring modifications to every filesystem) for
>little benefit - the current solution works in 99.9% of situations.

Yes, 99.9% accuracy is good and very useful, but a path that is
reported incorrectly is not good.  Fortunately validation (e.g., using
stat(2)) can help prevent the inaccuracy.  For 100% protection,
however, the stat(2) caller must have root permission to be able to
access any and all paths.

>Be sure to note that the information returned in /proc/<pid>/path
>_is_ guaranteed to be correct.  We perform the necessary validation on
>the stored path, and return no information (rather than incorrect
>information) if we cannot validate that it is correct.  It's also worth
>noting that the information has become quite a bit more reliable in
>Nevada build 21 and later, thanks to a slightly different
>interpositioning point.
>
>I would argue that having path information for unlinked vnodes is
>actually valuable, not a bug.  And as for renames, it too is an
>unsolvable problem, certainly at the VFS layer.  Imagine renaming a
>directory and having to update the path information for every child
>vnode on the system.  And storing a tree of pointers is not acceptable
>because the information must be calculable in arbitrary context in order
>to support the DTrace I/O provider, not to mention that there is no
>knowledge of vnode relationship at the VFS layer (and the DNLC is a
>partial solution used only by a few filesystems).

Because of the uncertainty that rename introduces, an unlinked file's
path is one that really can't be validated.  It probably should never
be reported.

>Suffice to say that the path information is behaving exactly as
>designed, and that there is no way to extend that design in an
>architecturally viable way (no changes outside the VFS layer) and
>maintining necessary constraints (DTrace observability, performance).

>Hope that helps.  Feel free to play around with the OpenSolaris source
>code if you think I'm wrong on either of these points.  You can find me
>(and more observability junkies) over at the observability community on
>opensolaris.org.
>--
>Eric Schrock, Solaris Kernel Development       http://blogs.sun.com/eschrock

Thank you for the information, Eric.

Vic Abell, lsof author
0
Reply abe 9/20/2005 7:23:02 PM

In article <abe.1127243937@quest.cc.purdue.edu>, Victor A Abell wrote:
>
>The vnode's v_path pointer is still set for unlinked open
>files to te address of a kernel string that contains the
>path under which the file was opened.  I just double-checked
>that with dbx on a Solaris 10 Amd64 generic kernel.
>
>The v_path pointer is also incorrect for files that have not
>been unlinked when the paths under which they have been opened
>have been changed -- i.e, with mv(1) or rename(2) has been
>applied.  This is true for the three Solaris 10 architectures
>-- Amd64, sun4u and i86pc -- where I have tested lsof.
>
>Is there a patch that fixes either or both problems?

The above "problems" are both intrinsic to the design of v_path.  The
path information was designed to aid in observability.  It never has had
any guarantee associated with it that it is currently correct, only that
it was correct at one point in time.  To do otherwise is to solve an
essentially unsolvable problem (thanks to hard links) and require a huge
amount of effort (requiring modifications to every filesystem) for
little benefit - the current solution works in 99.9% of situations.

Be sure to note that the information returned in /proc/<pid>/path
_is_ guaranteed to be correct.  We perform the necessary validation on
the stored path, and return no information (rather than incorrect
information) if we cannot validate that it is correct.  It's also worth
noting that the information has become quite a bit more reliable in
Nevada build 21 and later, thanks to a slightly different
interpositioning point.

I would argue that having path information for unlinked vnodes is
actually valuable, not a bug.  And as for renames, it too is an
unsolvable problem, certainly at the VFS layer.  Imagine renaming a
directory and having to update the path information for every child
vnode on the system.  And storing a tree of pointers is not acceptable
because the information must be calculable in arbitrary context in order
to support the DTrace I/O provider, not to mention that there is no
knowledge of vnode relationship at the VFS layer (and the DNLC is a
partial solution used only by a few filesystems).

Suffice to say that the path information is behaving exactly as
designed, and that there is no way to extend that design in an
architecturally viable way (no changes outside the VFS layer) and
maintining necessary constraints (DTrace observability, performance).

Hope that helps.  Feel free to play around with the OpenSolaris source
code if you think I'm wrong on either of these points.  You can find me
(and more observability junkies) over at the observability community on
opensolaris.org.

- Eric

--
Eric Schrock, Solaris Kernel Development       http://blogs.sun.com/eschrock
0
Reply Eric 9/20/2005 8:33:46 PM

In article <abe.1127262182@quest.cc.purdue.edu>, Victor A Abell wrote:
>
>Yes, 99.9% accuracy is good and very useful, but a path that is
>reported incorrectly is not good.  Fortunately validation (e.g., using
>stat(2)) can help prevent the inaccuracy.  For 100% protection,
>however, the stat(2) caller must have root permission to be able to
>access any and all paths.
>
>Because of the uncertainty that rename introduces, an unlinked file's
>path is one that really can't be validated.  It probably should never
>be reported.

I'd just like to emphasize for the readers out there that Victor's
qualms about the validity of path information only applies to the
correctness of the v_path as stored within the kernel.  It does not
apply to the paths as shown in /proc/<pid>/path/*.  These will always be
correct, and are validated within the kernel before being returned via
procfs.  You do _not_ need to worry about unlinked files or stat()ing
the results from reading these files.

For information on how this is done, see the implementation of
vnodetopath(), used by pr_readlink_lookup().

http://cvs.opensolaris.org/source/xref/usr/src/uts/common/fs/lookup.c#1347

- Eric

--
Eric Schrock, Solaris Kernel Development       http://blogs.sun.com/eschrock
0
Reply Eric 9/21/2005 3:26:48 AM

Eric.Schrock@sun.no.spam.com (Eric Schrock) writes:

>In article <abe.1127262182@quest.cc.purdue.edu>, Victor A Abell wrote:
>>
>>Yes, 99.9% accuracy is good and very useful, but a path that is
>>reported incorrectly is not good.  Fortunately validation (e.g., using
>>stat(2)) can help prevent the inaccuracy.  For 100% protection,
>>however, the stat(2) caller must have root permission to be able to
>>access any and all paths.
>>
>>Because of the uncertainty that rename introduces, an unlinked file's
>>path is one that really can't be validated.  It probably should never
>>be reported.

>I'd just like to emphasize for the readers out there that Victor's
>qualms about the validity of path information only applies to the
>correctness of the v_path as stored within the kernel.  It does not
>apply to the paths as shown in /proc/<pid>/path/*.  These will always be
>correct, and are validated within the kernel before being returned via
>procfs.  You do _not_ need to worry about unlinked files or stat()ing
>the results from reading these files.

>For information on how this is done, see the implementation of
>vnodetopath(), used by pr_readlink_lookup().

>http://cvs.opensolaris.org/source/xref/usr/src/uts/common/fs/lookup.c#1347

Eric is right.  The vnodetopath() code is very careful to validate the
path.  It uses v_path as a starting point, but if it can't be
validated, then a reverse-lookup takes place.  That's probably the best
of all worlds for the VFS design, since the v_path "hint" will usually
be correct.

As for how this applies to the original question about unlinked paths,
it appears that /proc/<pid>/path/... will not be a symbolic link to
anything if the file has been unlinked.  The hint remains in the
vnode's v_path, but there's no way to validate it.  It might sometimes
be useful to report the hint, if it could be shown as only a hint and
not a certainty.

Vic Abell, lsof author
0
Reply abe 9/21/2005 5:10:04 AM

Casper H.S. Dik <Casper.Dik@Sun.COM> writes:

>abe@quest.cc.purdue.edu (Victor A Abell) writes:

>>The vnode's v_path pointer is still set for unlinked open
>>files to te address of a kernel string that contains the
>>path under which the file was opened.  I just double-checked
>>that with dbx on a Solaris 10 Amd64 generic kernel.

>That's not the question I asked; the question I asked is:
>"is the /proc/<pid>/path incorrect in such cases"?

>If that's not the case then the value of v_path is
>irrelevant as the system treats it merely as a hint.

Sorry -- I didn't answer your question, did I?

/proc/<pid>/path/... will not be a symbolic link to anything if the
open file it represents has been unlinked.  The original path hint
remains in the vnode's v_path, however.  It might be useful to the OP
as a hint, could it be reported as just that.

Vic

0
Reply abe 9/21/2005 5:19:03 AM

abe@quest.cc.purdue.edu (Victor A Abell) writes:

>The vnode's v_path pointer is still set for unlinked open
>files to te address of a kernel string that contains the
>path under which the file was opened.  I just double-checked
>that with dbx on a Solaris 10 Amd64 generic kernel.

That's not the question I asked; the question I asked is:
"is the /proc/<pid>/path incorrect in such cases"?

If that's not the case then the value of v_path is
irrelevant as the system treats it merely as a hint.

Casper
-- 
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
0
Reply Casper 9/21/2005 8:07:25 AM

Casper H.S. Dik <Casper.Dik@Sun.COM> writes:

>abe@quest.cc.purdue.edu (Victor A Abell) writes:

>>The vnode's v_path pointer is still set for unlinked open
>>files to te address of a kernel string that contains the
>>path under which the file was opened.  I just double-checked
>>that with dbx on a Solaris 10 Amd64 generic kernel.

>That's not the question I asked; the question I asked is:
>"is the /proc/<pid>/path incorrect in such cases"?

>If that's not the case then the value of v_path is
>irrelevant as the system treats it merely as a hint.

Eric already answered this and it seems that you can indeed
trust /proc/*/path information but not v_path which is what
Vic cares about for lsof.

Casper
-- 
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
0
Reply Casper 9/21/2005 8:41:35 AM

Casper H.S. Dik <Casper.Dik@Sun.COM> writes:

>abe@quest.cc.purdue.edu (Victor A Abell) writes:

>>As for how this applies to the original question about unlinked paths,
>>it appears that /proc/<pid>/path/... will not be a symbolic link to
>>anything if the file has been unlinked.  The hint remains in the
>>vnode's v_path, but there's no way to validate it.  It might sometimes
>>be useful to report the hint, if it could be shown as only a hint and
>>not a certainty.

>Yes, but an unlinked file has no name, really ...

However, I think that's what the OP wanted to know.  It seems a useful
item of information to me to know the path name under which a deleted
file was opened.

>(Last time I checked, Linux also gets a number of cases wrong in
>/proc)

I've not seen that, but I have seen many cases where the Linux /proc
file system does get the path name correct, even after components of
the path have been renamed.  Moreover, Linux /proc reports "(deleted)"
at the end of the open file's last known path when the file has been
unlinked.

Lsof 4.77 will have an option to make a similar "(deleted)" report.
Anyone who wants a look at that can try this 4.77 pre-release:

ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/NEW/lsof_4.77A.sun.tar.bz2

The -X option must be specified to lsof 4.77 to get the "(deleted)"
path name report.  There are some new FAQ entries discussing the cached
vnode path name lsof uses.

Vic
0
Reply abe 9/21/2005 8:50:09 AM

abe@quest.cc.purdue.edu (Victor A Abell) writes:

>As for how this applies to the original question about unlinked paths,
>it appears that /proc/<pid>/path/... will not be a symbolic link to
>anything if the file has been unlinked.  The hint remains in the
>vnode's v_path, but there's no way to validate it.  It might sometimes
>be useful to report the hint, if it could be shown as only a hint and
>not a certainty.

Yes, but an unlinked file has no name, really ...

(Last time I checked, Linux also gets a number of cases wrong in
/proc)

Casper
-- 
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
0
Reply Casper 9/21/2005 12:35:32 PM

abe@quest.cc.purdue.edu (Victor A Abell) writes:

>I've not seen that, but I have seen many cases where the Linux /proc
>file system does get the path name correct, even after components of
>the path have been renamed.  Moreover, Linux /proc reports "(deleted)"
>at the end of the open file's last known path when the file has been
>unlinked.

There are a few cases with "ln/rm" which break.

A v_path implementation could be a linked list of vnodes all the
way up to the root so that it would construct the path on the fly
each time; that would fix a few of the corner cases.

The Solaris philosophy for "pseudo symlinks" is that they
return actual symlink content and not just hackish descriptive
text.

Casper
-- 
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
0
Reply Casper 9/21/2005 3:01:27 PM

how can that removed link( viz /proc/pid/path/1) can be identified. and who would unlink it ?

-jagadeesh-
0
Reply kjagadeeshkumar 2/3/2014 6:04:42 AM
comp.unix.solaris 25711 articles. 86 followers. Post

16 Replies
793 Views

Similar Articles

[PageSpeed] 37

  • Permalink
  • submit to reddit
  • Email
  • Follow


Reply:

Similar Artilces:

how to determine file name
Hello, I have a frame's onload event calling a function which needs to know which file was loaded. Is there any java object/method to determine the file name or any type of file id? Thanks, Asra Asra wrote: > Hello, > I have a frame's onload event calling a function which needs to know > which file was loaded. Is there any java object/method to determine > the file name or any type of file id? Not sure about a java object/method, you might try a Java group. JS can get it, rather simply actually, from the scenario you give: <frame onload="someFunction(this.src)&...

couldn't open pid file '/var/run/named.pid': Permission denied
HI I have installed installed bind 9.5.-dlz on FC7. When i am trying to start named it gives me the following error : [root@bind ~]# tail -f /var/log/messages Nov 15 15:47:11 bind named[15378]: automatic empty zone: 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA Nov 15 15:47:11 bind named[15378]: automatic empty zone: D.F.IP6.ARPA Nov 15 15:47:11 bind named[15378]: automatic empty zone: 8.E.F.IP6.ARPA Nov 15 15:47:11 bind named[15378]: automatic empty zone: 9.E.F.IP6.ARPA Nov 15 15:47:11 bind named[15378]: automatic empty zone: A.E.F.IP6.ARPA Nov 15 15:...

Re: couldn't open pid file '/var/run/named.pid': Permission denied
- /var/run/named.pid + /var/run/named/named.pid Looks like the path was wrong On 15/11/07 5:00 PM, "Pawe� Tobi�" <ptobis@interia.pl> wrote: > Wasn't it a selinux issue? > > Regards > Pawel Tobis > > > ---------------------------------------------------------------------- > Poznaj wschodzace gwiazdy polskiej muzyki! > Sluchaj i oceniaj >>> http://link.interia.pl/f1c66 > > -- Kal Feher Team Leader Network Services and Production Support Melbourne IT Ltd Level 2, 120 King Street Melbourne Victoria 3...

Name of file that contains proc
Hello all, I'm wondering how to get the filename of the file that contains the procedure, when I run the procedure. For example, if I have file functions.tcl that contains this proc my_name, like so: ===functions.tcl=== proc my_name { } { puts ?????; } =============== Then if I go run tclsh, source functions.tcl, and run my_name, it should displays "functions.tcl". I tried global argv0, that gives me the name of the executable, [info script] gives me nothing (it works if I don't put it in the proc), and of course [info nameofexecutable] gives me /usr/bin/tclsh. Any he...

Reading proc/pid/mem File
(Figured it deserves a different thread). I'm trying to read a different process's proc/pid/mem file given I know it's pid. here's my code: ===START string fn = "/proc/pid/mem"; //where pid is the right pid int fd = open(fn.c_str(), O_RDONLY); char* buff = new char[BUFF_SIZE]; int size = read(fd, buff, BUFF_SIZE); ===END No matter what BUFF_SIZE is, or whether I use lseek before (to change the cursur to a specific location), read always returns -1. I tried running the process with sudo but still no success. Any ideas? Thanks! --sternr sternr &...

Proc export file name with %let
I am sure this is very simple and appreciate any help you can lend: Here is a part of my code, run from UNIX: %let day=date()-1; %let filename =filename&day..csv; data lookup; set mydataset (keep =var1 var2 var3); where var3 > date()-130; run; PROC EXPORT DATA= lookup OUTFILE= "&filename." DBMS=CSV REPLACE; The problem is in the export. I want my outfile to be named filename20060807 but what I am getting is filenamedate()-1. I am sure this is something simple but I can't figure out how to get the date I calculate in my first %let state...

Determine Computer Name That is Accessing File
I have been trying to find some API routines that will allow me to determine the name of the computer that is accessing a file on a server. I have found the NetFileEnum call (returns the names of the files in use and the names of the users accessing them). I have also found the NetConnectionEnum call (returns the name of the computer that is accessing a share). I do not see any way of correlating the data that these two api calls return. Can anyone point me in the right direction? Thanks. -Vincent Hi Vincent, This function (see below) will return the name of the local computer, if you...

Reading proc/pid/mem File
(Figured it deserves a different thread). I'm trying to read a different process's proc/pid/mem file given I know it's pid. here's my code: ===START string fn = "/proc/pid/mem"; //where pid is the right pid int fd = open(fn.c_str(), O_RDONLY); char* buff = new char[BUFF_SIZE]; int size = read(fd, buff, BUFF_SIZE); ===END No matter what BUFF_SIZE is, or whether I use lseek before (to change the cursur to a specific location), read always returns -1. I tried running the process with sudo but still no success. Any ideas? Thanks! --sternr sternr &...

[9fans] /proc/$pid/fd not mp safe
i haven't dug into the code yet, but it appears that /proc/fd isn't fd safe. note fd 7: minooka; cat /proc/xxxxxxx/fd / 0 r M 71 (0000000000000001 0 00) 8192 37 /mnt/term/dev/cons 1 w c 0 (000000000000000a 0 00) 0 189454 /dev/null 2 w c 0 (000000000000000a 0 00) 0 189454 /dev/null 3 r / 0 (0000000000000000 0 80) 0 776 / 4 r M 55 (0000000000000ade 27 80) 8192 1651 /mnt 5 r M 71 (0000000000000000 0 80) 65512 2939 /mnt/term 6 r M 71 (00000000000005c6 89 80) 8192 3683 /mnt/term/386 7 r M 71 (...

ODS, proc gplot, gif file name
Hello, I'm using ODS with proc gplot to generate web pages that display the gif images produced by gplot. Everything works fine, but I would like to be able to explicitly specify the names of the gif files that ODS/gplot is producing, programmatically from within the SAS session. Currently, the file names are generated automatically and incorporate a sequential index ... I'd like to override this default with meaningful names of my own. Dear Sawpit, You can use the name= -option in the plot-statement, but if you run the gplot-procedure multiple times they too will generate indexes. ...

Howto Determine mimetype without the file name extension?
Hi all, I had a filesystem crash and when I retrieved the data back the files had random names without extension. I decided to write a script to determine the file extension and create a newfile with extension. --- method 1: # File extension utility. import os import mimetypes import shutil def main(): for root,dirs,files in os.walk(r'C:\Senthil\test'): for each in files: fname = os.path.join(root,each) print fname mtype,entype = mimetypes.guess_type(fname) fext = mimetypes.guess_extension(mtype) if fex...

Determining name/paths of source-d files at runtime
Hi Is there a way in TCL to know (at runtime): 1. Name/Path of all files sourced using source command 2. Name/Path of the file containing a a proc, for e.g., foo, assuming that the file is sourced in the interpreter and the function definition is availble. 3. Name/Path of the file containing a a proc, for e.g., foo, assuming that the file is sourced in the interpreter and the function definition is availble and the function is invoked. In other words, if I want to display the path/name of the file and function name upon invocation. Any info. will be of great help. Regard Sharad Sharad sch...

Reading /proc/<pid>/maps file
Hi, I want to dump the virtual memory map of my process, and it seems like I can get this from the /proc/<pid>/maps file. The trouble is, when I try to loop over this file until EOF, I never get EOF and if I try to calculate the length of the file, its turning out to be zero! Here is a small snippet that demonstrates the problem with calculating the filelength. #include <stdio.h> #include <stdlib.h> #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> #include <unistd.h> #include <assert.h> int main(int argc, char...

Determine name of m-file from within code during runtime
I would like to have an m-code automatically determine the filename under which it is saved ... any ideas? FYI, the reason for this is so that I can tag the output that the code generates with the specific code filename that generated it. I do not want to use a variable that must be set by the programmer (the code is modified and saved under a different filename frequently and there is a good chance the user will forget to update the variable). Thanks in advance, Todd On Wed, 17 Dec 2008 19:58:03 +0000 (UTC), "Todd " <sorry@cannot.provide> wrote: >I would like to have an...

Determine the process name which created a new file or a directory in Windows?
I am trying to programatically determine a way to find out which process created a new file or directory in a given volume in Windows Operating Systems using Visual C++. Win32 API provides the following function which let's you know when a new file or directory is created but doesn't let you know the process name that created it: BOOL ReadDirectoryChangesW(HANDLE hDirectory, LPVOID lpBuffer, DWORD nBufferLength, BOOL bWatchSubTree, DWORD dwNotifyFilter, LPDWORD lpBytesReturned, LPOVERLAPPED lpOverlapped, LPOVERLAPPED_COMPLETION_ROUTINE lpCompletionROutine); Is there an ...

AIX 6.1: Change default core file name from core to core.pid.ddhhmmss
I have reviewed the man page, but it isn't clear to me how I can change the default name of a core file that is generate when running kill -6 PID. I have tried 'chcore -n on' Any ideas? On 26 Aug, 04:04, Ouray Viney <ovi...@gmail.com> wrote: > I have reviewed the man page, but it isn't clear to me how I can > change the default name of a core file that is generate when running > kill -6 PID. > > I have tried 'chcore -n on' > > Any ideas? Try logging out and then back in - worked for me on AIX 5.2 and AIX 6.1. On Aug 26, 6:31=A0am, sjm <...

Win32-C -> Get proc name, pid & windows title of Active Window
Hi, I'm needing code a funcition that identify what app have the windows focus setted and get the pid, window title and proc name of it. I tryed use GetFocus(), looked at MSDN, but i couldn't found how to do it. :( Someone can give a help and if possible a example ? Regards. "Zelos" <zgrp_zgrp@yahoo.com.br> wrote in message news:b888642c.0406231215.176a8543@posting.google.com... > I'm needing code a funcition that identify what app have the windows > focus setted and get the pid, window title and proc name of it. focus - GetFocus (but...

"Permission denied" while reading file /proc/<pid>/maps with permissions '-r--r--r--'
Hi, Could anybody explain why we have 'Permission denied' here? Thanks > uname -a Linux machine1 2.6.32-279.el6.x86_64 #1 SMP Wed Jun 13 18:24:36 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux > id uid=75308(user1) gid=100(users) groups=100(users) > ps -ef | grep 25796 root 25796 15752 0 15:11 pts/30 00:00:00 ssh -l root machine2 user1 26737 13908 0 15:19 pts/23 00:00:00 grep 25796 > ls -ld /proc/25796/maps -r--r--r-- 1 root root 0 Oct 2 15:12 /proc/25796/maps > cat /proc/25796/maps cat: /proc/25796/maps: Permission denied Alex V...

Linux: "Permission denied" while reading file /proc/<pid>/maps with permissions '-r--r--r--'
Hi, Could anybody explain why we have 'Permission denied' here? Thanks > uname -a Linux machine1 2.6.32-279.el6.x86_64 #1 SMP Wed Jun 13 18:24:36 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux > id uid=75308(user1) gid=100(users) groups=100(users) > ps -ef | grep 25796 root 25796 15752 0 15:11 pts/30 00:00:00 ssh -l root machine2 user1 26737 13908 0 15:19 pts/23 00:00:00 grep 25796 > ls -ld /proc/25796/maps -r--r--r-- 1 root root 0 Oct 2 15:12 /proc/25796/maps > cat /proc/25796/maps cat: /proc/25796/maps: Permission de...

output file name based on original file name
I have a simple txt parsing script that I'd like to have the output be named after the original text file. original = original.txt output = original_output.txt I'm just doing a simple file.open, and couldn't find anything. File.open('output.txt', 'w') do |f2| File.readlines("original.txt").each do |line| Thanks in advance for any help. -- Posted via http://www.ruby-forum.com/. Collin Moore wrote: > I have a simple txt parsing script that I'd like to have the output be > named after the original text file. > > original = original.tx...

automatic naming of files based on the readed file name?
Using "write labview measurement file" and "read labview measurement file". For example: Readed_file.dat Readed_file_written.dat ...

How to pass NCDF files name to text files names?
Folks I am reading some NCDF files like this: pathName=3D"d:\p\" List =3D findfile(pathName+"*.nc") nosFiles=3DN_ELEMENTS(List) data =3D ptrarr(nosFiles) for i =3D 0, nosFiles - 1 do begin ncid =3D NCDF_OPEN(list[i]) NCDF_VARGET, ncid, 0, lon NCDF_VARGET, ncid, 1, lat NCDF_VARGET, ncid, 2, concentration NCDF_CLOSE, ncid ; Close the NetCDF file *Here I need to save all of my files (in text format) in arrays with 3 columns and with name of NCDF file that I am reading (for instance: L3b_20070716.txt, L3b_20070717 and so on)* Endfor In another word I need to pass my NCD...

How to copy a file to a file with a prefixed file name
I'm trying to write a program that will archive selected files to an archive directory. The files in the archive directory will have a prefix in the format yyyymmdd-hhmmss-filename.ext. So, if the file is called "somefile.dat", then the filename in the archive directory should be "20090522-164325-somefile.dat". I'm using Clipper's COPY FILE command to do the copy. I can't figure out how to get the prefix in front of the file name. Creating the prefix string is no problem, but I can't figure out how to tack that onto the front of the filename. If I...

How to get short file name (8.3) from long file name
Hello Group, Any way in xHarbour to get the short file name, i.e. xxxxxx~1.ext, from a long file name? I want to use an old utility program that accepts only short file names with the RUN command. Klaus has a Clipper function in his LF_ library but since I am working with a large file, I want to see if xHarbour can process it faster. (btw, thanks again Klaus, for the LF_ library). Thanks, Ted On Mar 12, 7:27 am, Ted <ted.kobaya...@gmail.com> wrote: > Hello Group, > > Any way in xHarbour to get the short file name, i.e. xxxxxx~1.ext, > from a long file name? I want to ...