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 (1) 2/3/2014 6:04:42 AM
comp.unix.solaris 25805 articles. 88 followers. Post

16 Replies
1101 Views

Similar Articles

[PageSpeed] 29


  • 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)&...

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...

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...

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...

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...

How to get the file name from a String containing the path plus the file name?
Hi, I have a String "dirA/dirB/dirC/file.txt". How to use String manipulation technique to get "file.txt"? String fullName = "dirA/dirB/dirC/file.txt"; int index = fullName.lastIndexOf("\\"); //here is a problem, if I try lastIndexOf("\"), there is a compile error String fileName = fullName.subString(index); //but does not work Thank you very much. ps: I am working on linux. www wrote: > Hi, > > I have a String "dirA/dirB/dirC/file.txt". How to use String > manipulation technique to get "...

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 ...

how do I tell a browser the name of a file, for download, if the file has open space in its name?
I've got a music studio for a client. Their whole studio is run with Macintosh computers. Macintosh computers allow file names to have open white spaces, such as "animal hospital.mp3". I have a download script, so customers on the website can download MP3s to their harddrive (rather than merely listen to it in their browsers): $fileToBuy = $_GET["fileToBuy"]; if ($fileToBuy) { $pathToFile = "temporary_files/$fileToBuy"; if (!file_exists($pathToFile)) $pathToFile = "site_specific_files/ $fileToBuy"; if (!file_exists($pathToFile)) $pathToFile =...

[ace-users] Re: Too long file names and duplicate file names.
Hi David, > I attach the .DOC file with the errors. Great, thanks very much! I've put this file at http://www.dre.vanderbilt.edu/~schmidt/Doc_unzip.doc in case people are interested. > The Y/N char in blue next to each of the duplicate indicates what > was my response to the choices. I chose "Y" when the second file > was larger or have a more recent date, which is of course stupid... > because I figured out later that we are talking about different > files by their content. All of these files are documentation files auto-generated by D...

Admin Process: File name: NAMES.NSF; Name:
As Administrator I recently change my name. Now every time the AdminP start I get this. 2005-02-09 04:59:03 Admin Process: File name: NAMES.NSF; Name: << MY OLD NAME>> : User name not found in Name and Address Book What have I missed ? Where to look TIA. "McDuff" <Mc@Duff.is> wrote: >As Administrator I recently change my name. > >Now every time the AdminP start I get this. > >2005-02-09 04:59:03 Admin Process: File name: NAMES.NSF; Name: << MY OLD >NAME>> : User name not found in Name and Address Book > ...

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 &...

how to extract path/file name upto the mzximum of two levels from the file name?
Dear Group, I have a input file with the following details, $ cat my_input.dat /A1/b1/c1/file1 /A1/b1/file1 /A2/b1/c1/d1/file2 /A2/b1/file1 /A2/b2/file1 /A3/file1 /A3 /A4 I want to get only the first two levels. I will "unique" this ouput and the final reault has to be, /A1/b1 /A2/b1 /A2/b2 /A3/filename /A3 /A4 (ie, the extracted files/path will have a maximum of two "/" s) How would I get this done in ksh? (awk/sed anything is fine) Thanks... On 2005-10-28, da wrote: > Dear Group, > > I have a input file with the following details, > > $ cat my_inp...

rename all the file names in a directory so that the first character of each file name is lower case
How to rename all the file names in a directory so that the first character of each file name is lower case in the bash shell? e.g. old file names are: Certificates General Util.dsp new file names become: certificates general util.dsp On 2008-09-07, TsanChung wrote: > How to rename all the file names in a directory so that the first > character of each file name is lower case in the bash shell? > e.g. > old file names are: > Certificates > General > Util.dsp > > new file names become: > certificates > general > util.dsp _lwr() { _LWR= case $1 in ...

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...

[ace-users] Re: Too long file names and duplicate file names. #2
Hi, > Johnny and Doug > > 1. Doc tools > I am not familiar with using Doxygen but any decent doc generator that > deserve to be called automatic, should be able, upon the change of a > name to also change all the pointers/hyperlinks that point to that name > respectively automatically. The problem is that we do have pages written outselves that refer to the doxygen generated names. Those are then broken. Johnny ...

Downloading blob will save the file by the procedure name and not the actual file name
Hi, I am using PL/SQL web toolkit to open documents in a browser. The documents are stored as BLOB data types. I am using the below procedure "viewer.sql" to open the documents based on the mime types. My question: When I try to save the opened document, I see that the file name is that of the procedure name in the URL and not the actual filename. I have the filename stored in the database. Is there a way to change the filename? Actual code.... CREATE OR REPLACE PROCEDURE VIEWER (DOC_LOC IN NUMBER,D_ID IN NUMBER) AS V_file_ext VARCHAR2(5) V_blob BLOB; ...

logical puzzle: how to generate reasonable archive file names from file and directory names
I'm writing a module to convert between filesystem nodes (directory,file) and various archives (gz, zip, tgz). For this I want to automatically create reasonable file names for the archives where these file names depend from the type of the file system node to be archived and from the type of the archive to be created. I want the following transformations to take place: Dir abc =(gz)=> *not allowed* =(zip,tgz)=> abz.zip,abc.tgz abc.XY =(gz)=> *not allowed* =(zip,tgz)=> abc.XY.zip,abc.XY.tgz File abc =(gz)=> abc.gz...

RE: [ace-users] Re: Too long file names and duplicate file names.
From: Douglas C. Schmidt [mailto:schmidt@cse.wustl.edu] > As mentioned before, these files differ in terms of their > spelling, which works fine on most non-Windows platforms, but > fails on Windows. > [snip] > If anyone knows how to address this problem so things work on Windows that > would be great, but it's not a showstopper. Hi, 1) About case sensitivity in file names: Doxygen has the CASE_SENSE_NAMES option, documented as: # If the CASE_SENSE_NAMES tag is set to NO then Doxygen will only generate # file names in lower-case letters. If set t...

Downloading blob will save the file by the procedure name and not the actual file name
Hi, I am using PL/SQL web toolkit to open documents in a browser. The documents are stored as BLOB data types. I am using the below procedure "viewer.sql" to open the documents based on the mime types. My question: When I try to save the opened document, I see that the file name is that of the procedure name in the URL and not the actual filename. I have the filename stored in the database. Is there a way to change the filename? Actual code.... CREATE OR REPLACE PROCEDURE VIEWER (DOC_LOC IN NUMBER,D_ID IN NUMBER) AS V_file_ext VARCHAR2(5) V_blob BLOB; ...

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 &...