Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #158297 > unrolled thread

Finding the name of a file

Back to article view | Back to comp.lang.c

Contents

  Finding the name of a file emanuele cannizzo <emacannizzo@gmail.com> - 2021-01-12 07:26 -0800
    Re: Finding the name of a file Bart <bc@freeuk.com> - 2021-01-12 16:14 +0000
      Re: Finding the name of a file scott@slp53.sl.home (Scott Lurndal) - 2021-01-12 17:02 +0000
    Re: Finding the name of a file Christian Hanné <the.hanne@gmail.com> - 2021-01-12 17:29 +0100
      Re: Finding the name of a file scott@slp53.sl.home (Scott Lurndal) - 2021-01-12 17:03 +0000
      Re: Finding the name of a file antispam@math.uni.wroc.pl - 2021-01-12 19:52 +0000
    Re: Finding the name of a file Mark Bluemel <mark.bluemel@gmail.com> - 2021-01-12 08:37 -0800
    Re: Finding the name of a file Anton Shepelev <anton.txt@g{oogle}mail.com> - 2021-01-12 19:41 +0300
      Re: Finding the name of a file Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-01-12 09:34 -0800
        Re: Finding the name of a file Anton Shepelev <anton.txt@g{oogle}mail.com> - 2021-01-12 20:56 +0300
    Re: Finding the name of a file Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2021-01-12 09:42 -0700
      Re: Finding the name of a file Bart <bc@freeuk.com> - 2021-01-12 16:56 +0000
        Re: Finding the name of a file Anton Shepelev <anton.txt@g{oogle}mail.com> - 2021-01-12 19:58 +0300
        Re: Finding the name of a file Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2021-01-12 11:25 -0700
        Re: Finding the name of a file antispam@math.uni.wroc.pl - 2021-01-12 20:12 +0000
          Re: Finding the name of a file Bart <bc@freeuk.com> - 2021-01-12 20:29 +0000
            Re: Finding the name of a file antispam@math.uni.wroc.pl - 2021-01-12 22:14 +0000
              Re: Finding the name of a file Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-01-12 15:12 -0800
                Re: Finding the name of a file Jorgen Grahn <grahn+nntp@snipabacken.se> - 2021-01-15 07:41 +0000
                  Re: Finding the name of a file Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-15 09:54 -0800
                    Re: Finding the name of a file Jorgen Grahn <grahn+nntp@snipabacken.se> - 2021-01-15 21:02 +0000
                      Re: Finding the name of a file Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2021-01-15 18:30 -0700
                        Re: Finding the name of a file Jorgen Grahn <grahn+nntp@snipabacken.se> - 2021-01-16 07:47 +0000
                          Re: Finding the name of a file Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-20 09:11 -0800
                            Re: Finding the name of a file Siri Cruise <chine.bleu@yahoo.com> - 2021-01-20 09:39 -0800
                              Re: Finding the name of a file Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-23 08:52 -0800
                                Re: Finding the name of a file Vir Campestris <vir.campestris@invalid.invalid> - 2021-01-25 21:43 +0000
                                  Re: Finding the name of a file scott@slp53.sl.home (Scott Lurndal) - 2021-01-25 23:47 +0000
                                  Re: Finding the name of a file Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-27 07:55 -0800
                      Re: Finding the name of a file Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-20 09:06 -0800
    Re: Finding the name of a file Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-12 18:18 +0000
    Re: Finding the name of a file Manfred <noname@add.invalid> - 2021-01-15 20:12 +0100
      Re: Finding the name of a file scott@slp53.sl.home (Scott Lurndal) - 2021-01-15 19:55 +0000
        Re: Finding the name of a file Manfred <noname@add.invalid> - 2021-01-16 02:06 +0100

Page 2 of 2 — ← Prev page 1 [2]

#158382

On Fri, 2021-01-15, Tim Rentsch wrote:
> Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
>
>> On Tue, 2021-01-12, Keith Thompson wrote:
>> ...
>>
>>> To be clear, this is true of Unix-like systems (and /proc is more or
>>> less Linux-specific, though some other Unix-like systems may support
>>> it).  The original post in this thread didn't specify an operating
>>> system or file system.
>>
>> The OP was simply asking about the standard C library, if there is
>> a name_of(FILE*).  [...]
>
> The top-of-thread posting that I saw said this (some white space
> added):
>
>     Let assume that I have created a pointer to a File and
>     I opened a file in some mode.
>
>     For example:  FILE*  fp = fopen("example.txt", "r")
>
>     I want to know if there is any function that takes as
>     parameter the file pointer fp and returns the name of
>     the file "example.txt" and the mode "r".
>
> I don't see anything there that says he is asking (only) about
> the standard C library.  What he wants to know is about "any
> function".  Are you referring to some other comment that I may
> have missed?

No, that's what I read, and combined with the fact that he asked in
comp.lang.c.  If he had asked in comp.unix.programmer, I suppose there
could have been such a function in a Unix libc.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#158387

Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
> On Fri, 2021-01-15, Tim Rentsch wrote:
>>
>>     I want to know if there is any function that takes as
>>     parameter the file pointer fp and returns the name of
>>     the file "example.txt" and the mode "r".
>>
>> I don't see anything there that says he is asking (only) about
>> the standard C library.  What he wants to know is about "any
>> function".  Are you referring to some other comment that I may
>> have missed?
>
> No, that's what I read, and combined with the fact that he asked in
> comp.lang.c.  If he had asked in comp.unix.programmer, I suppose there
> could have been such a function in a Unix libc.

To have simply said "no" if in fact there were a way to do it (even if
not in the C standard library) would have been pretty obnoxious.  Much
better to answer "no, and it may not even be possible.  Here's a way to
approximate it", as pretty much everybody did.

[toc] | [prev] | [next] | [standalone]

#158394

On Sat, 2021-01-16, Joe Pfeiffer wrote:
> Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
>> On Fri, 2021-01-15, Tim Rentsch wrote:
>>>
>>>     I want to know if there is any function that takes as
>>>     parameter the file pointer fp and returns the name of
>>>     the file "example.txt" and the mode "r".
>>>
>>> I don't see anything there that says he is asking (only) about
>>> the standard C library.  What he wants to know is about "any
>>> function".  Are you referring to some other comment that I may
>>> have missed?
>>
>> No, that's what I read, and combined with the fact that he asked in
>> comp.lang.c.  If he had asked in comp.unix.programmer, I suppose there
>> could have been such a function in a Unix libc.
>
> To have simply said "no" if in fact there were a way to do it (even if
> not in the C standard library) would have been pretty obnoxious.  Much
> better to answer "no, and it may not even be possible.  Here's a way to
> approximate it", as pretty much everybody did.

Much better IMO to reply "no; do you want it, and if so for what
purpose?"

I have opinions myself on how to deal with open files versus file
names, but they are limited to my use cases and to Unix, so I wouldn't
want to confuse someone with drastically different use cases by
describing them.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#158487

Jorgen Grahn <grahn+nntp@snipabacken.se> writes:

> On Sat, 2021-01-16, Joe Pfeiffer wrote:
>
>> Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
>>
>>> On Fri, 2021-01-15, Tim Rentsch wrote:
>>>
>>>>     I want to know if there is any function that takes as
>>>>     parameter the file pointer fp and returns the name of
>>>>     the file "example.txt" and the mode "r".
>>>>
>>>> I don't see anything there that says he is asking (only) about
>>>> the standard C library.  What he wants to know is about "any
>>>> function".  Are you referring to some other comment that I may
>>>> have missed?
>>>
>>> No, that's what I read, and combined with the fact that he asked in
>>> comp.lang.c.  If he had asked in comp.unix.programmer, I suppose there
>>> could have been such a function in a Unix libc.
>>
>> To have simply said "no" if in fact there were a way to do it (even if
>> not in the C standard library) would have been pretty obnoxious.  Much
>> better to answer "no, and it may not even be possible.  Here's a way to
>> approximate it", as pretty much everybody did.
>
> Much better IMO to reply "no; do you want it, and if so for what
> purpose?"

I suggest something like this:  "What I think you're asking is
for any function that will give you the information you're
looking for.  There is no such function in purely standard C,
but there are some functions that may be what you're looking
for in Unix or Posix environments.  Some examples are (names
of candidates here).  Does this help answer your question, or
if not is there more you can say about what it is you're trying
to do?"

[toc] | [prev] | [next] | [standalone]

#158491

In article <868s8no7n7.fsf@linuxsc.com>,
 Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

> I suggest something like this:  "What I think you're asking is
> for any function that will give you the information you're
> looking for.  There is no such function in purely standard C,
> but there are some functions that may be what you're looking
> for in Unix or Posix environments.  Some examples are (names
> of candidates here).  Does this help answer your question, or
> if not is there more you can say about what it is you're trying
> to do?"

Hint: Not really in unix. The problem in unix is a name and a 
file are different concepts. You can have an open file that 
appears nowhere in the directories. Also file can be linked to 
any number of names. You can get the file identifiers and search 
the directory hierarchy.

lsof list links to open files of a process when the links are 
known.

-- 
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted.    @
'I desire mercy, not sacrifice.'                                    /|\
Discordia: not just a religion but also a parody. This post         / \
I am an Andrea Doria sockpuppet.                  insults Islam.  Mohammed

[toc] | [prev] | [next] | [standalone]

#158578

Siri Cruise <chine.bleu@yahoo.com> writes:

> In article <868s8no7n7.fsf@linuxsc.com>,
>  Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> I suggest something like this:  "What I think you're asking is
>> for any function that will give you the information you're
>> looking for.  There is no such function in purely standard C,
>> but there are some functions that may be what you're looking
>> for in Unix or Posix environments.  Some examples are (names
>> of candidates here).  Does this help answer your question, or
>> if not is there more you can say about what it is you're trying
>> to do?"
>
> Hint:  Not really in unix.  [..elaboration..]

Understood.  Note that I said there are functions "that _may_ be"
what is being looked for.  I think it's possible that some Unix
functions could supply a satisfactory answer, but of course we
don't know since it isn't clear what the OP's requirements are.

[toc] | [prev] | [next] | [standalone]

#158613

On 23/01/2021 16:52, Tim Rentsch wrote:
> Siri Cruise <chine.bleu@yahoo.com> writes:
> 
>> In article <868s8no7n7.fsf@linuxsc.com>,
>>   Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>
>>> I suggest something like this:  "What I think you're asking is
>>> for any function that will give you the information you're
>>> looking for.  There is no such function in purely standard C,
>>> but there are some functions that may be what you're looking
>>> for in Unix or Posix environments.  Some examples are (names
>>> of candidates here).  Does this help answer your question, or
>>> if not is there more you can say about what it is you're trying
>>> to do?"
>>
>> Hint:  Not really in unix.  [..elaboration..]
> 
> Understood.  Note that I said there are functions "that _may_ be"
> what is being looked for.  I think it's possible that some Unix
> functions could supply a satisfactory answer, but of course we
> don't know since it isn't clear what the OP's requirements are.
> 

Just to point out that the file handle you have in you hand might not 
have a name.

On Unix-like systems it's possible to rename or even "delete" a file 
while it is open - which will remove the filename from the filesystem. 
But not the inode and the data.

Andy

[toc] | [prev] | [next] | [standalone]

#158618

Vir Campestris <vir.campestris@invalid.invalid> writes:
>On 23/01/2021 16:52, Tim Rentsch wrote:
>> Siri Cruise <chine.bleu@yahoo.com> writes:
>
>> Understood.  Note that I said there are functions "that _may_ be"
>> what is being looked for.  I think it's possible that some Unix
>> functions could supply a satisfactory answer, but of course we
>> don't know since it isn't clear what the OP's requirements are.
>> 
>
>Just to point out that the file handle you have in you hand might not 
>have a name.
>
>On Unix-like systems it's possible to rename or even "delete" a file 
>while it is open - which will remove the filename from the filesystem. 
>But not the inode and the data.

On some systems I've used, the file isn't even added to the directory
until it's closed with the 'save' option, otherwise it's considered
an unnamed temporary file.

[toc] | [prev] | [next] | [standalone]

#158651

Vir Campestris <vir.campestris@invalid.invalid> writes:

> On 23/01/2021 16:52, Tim Rentsch wrote:
>
>> Siri Cruise <chine.bleu@yahoo.com> writes:
>>
>>> In article <868s8no7n7.fsf@linuxsc.com>,
>>>   Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>>
>>>> I suggest something like this:  "What I think you're asking is
>>>> for any function that will give you the information you're
>>>> looking for.  There is no such function in purely standard C,
>>>> but there are some functions that may be what you're looking
>>>> for in Unix or Posix environments.  Some examples are (names
>>>> of candidates here).  Does this help answer your question, or
>>>> if not is there more you can say about what it is you're trying
>>>> to do?"
>>>
>>> Hint:  Not really in unix.  [..elaboration..]
>>
>> Understood.  Note that I said there are functions "that _may_ be"
>> what is being looked for.  I think it's possible that some Unix
>> functions could supply a satisfactory answer, but of course we
>> don't know since it isn't clear what the OP's requirements are.
>
> Just to point out that the file handle you have in you hand might not
> have a name.
>
> On Unix-like systems it's possible to rename or even "delete" a file
> while it is open - which will remove the filename from the
> filesystem.  But not the inode and the data.

Yes, I knew all that.  I don't think it changes any of what
I said.

[toc] | [prev] | [next] | [standalone]

#158486

Jorgen Grahn <grahn+nntp@snipabacken.se> writes:

> On Fri, 2021-01-15, Tim Rentsch wrote:
>
>> Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
>>
>>> On Tue, 2021-01-12, Keith Thompson wrote:
>>> ...
>>>
>>>> To be clear, this is true of Unix-like systems (and /proc is more or
>>>> less Linux-specific, though some other Unix-like systems may support
>>>> it).  The original post in this thread didn't specify an operating
>>>> system or file system.
>>>
>>> The OP was simply asking about the standard C library, if there is
>>> a name_of(FILE*).  [...]
>>
>> The top-of-thread posting that I saw said this (some white space
>> added):
>>
>>     Let assume that I have created a pointer to a File and
>>     I opened a file in some mode.
>>
>>     For example:  FILE*  fp = fopen("example.txt", "r")
>>
>>     I want to know if there is any function that takes as
>>     parameter the file pointer fp and returns the name of
>>     the file "example.txt" and the mode "r".
>>
>> I don't see anything there that says he is asking (only) about
>> the standard C library.  What he wants to know is about "any
>> function".  Are you referring to some other comment that I may
>> have missed?
>
> No, that's what I read, and combined with the fact that he asked in
> comp.lang.c.  [...]

I don't automatically assume a question asked in comp.lang.c
is only about standard C.  Especially not with a question
like this one, where if someone is aware of the distinction
there is a good chance they would know enough to be to find
the answer without asking.

[toc] | [prev] | [next] | [standalone]

#158311

On 2021-01-12, emanuele cannizzo <emacannizzo@gmail.com> wrote:
> Let assume that I have created a pointer to a File and I opened a file in some mode.
> For example: FILE*  fp = fopen("example.txt", "r")
> I want to know if there is any function that takes as parameter the
> file pointer fp and returns the name of the file "example.txt" and the
> mode "r".

On the Linux kernel, there is the following nonportable way, at least if
the /proc filesystem is correctly mounted as usual. (There are
situations where that might not hold.)

For each process, there is a /proc/<pid> directory full of information
about the process, where <pid> is the process ID of the process as a
decimal string.

The /proc/<pid>/fd directory contains information about the file
descriptor table of the process.

In the shell, $$ expands to the shell's own process ID, so we can
explore this:

$ ls -l /proc/$$/fd
total 0
lrwx------ 1 kaz kaz 64 Jan 12 07:28 0 -> /dev/pts/1
lrwx------ 1 kaz kaz 64 Jan 12 07:28 1 -> /dev/pts/1
lrwx------ 1 kaz kaz 64 Jan 12 07:28 2 -> /dev/pts/1
lrwx------ 1 kaz kaz 64 Jan 12 07:28 255 -> /dev/pts/1

To use this in a C program, we can do something like:

#include <limits.h>
#include <unistd.h>
#include <stdio.h>
#include <errno.h>
#include <string.h>

#ifdef __linux__

/* Returns NULL if an error occurs; errno is the same
   as for readlink, or possibly ENOMEM.
   The returned string is dynamically allocated by
   malloc; the caller owns it and can free it.  */

char *filename(FILE *stream)
{
   pid_t self = getpid();
   int fd = fileno(stream);
   char path[128];
   char buf[PATH_MAX];
   ssize_t nbytes;
   char *copy;

   sprintf(path, "/proc/%ld/fd/%d", (long) self, fd);

   nbytes = readlink(path, buf, sizeof buf);

   if (nbytes == -1)
      return NULL;

   if (nbytes == sizeof buf) {
      errno = ENAMETOOLONG;
      return NULL;
   }

   if ((copy = strdup(buf)) == NULL)
      errno = ENOMEM;

   return copy;
}

#endif

You can fix this to eliminate the PATH_MAX limit and whatever other
issues

-- 
TXR Programming Language: http://nongnu.org/txr

[toc] | [prev] | [next] | [standalone]

#158377

On 1/12/2021 4:26 PM, emanuele cannizzo wrote:
> Let assume that I have created a pointer to a File and I opened a file in some mode.
> For example: FILE*  fp = fopen("example.txt", "r")
> I want to know if there is any function that takes as parameter the file pointer fp and returns the name of the file "example.txt" and the mode "r".
> 

Others have answered about the file name.
Unless I've missed something, no answer has been given about the file-mode.
File-mode information can be retrieved by "fstat" (or "_fstat" on 
Windows) in <sys/stat.h>, at least under Windows this includes 
read/write information.
This is not an ISO C standard function either, it belongs to POSIX instead.

[toc] | [prev] | [next] | [standalone]

#158379

Manfred <noname@add.invalid> writes:
>On 1/12/2021 4:26 PM, emanuele cannizzo wrote:
>> Let assume that I have created a pointer to a File and I opened a file in some mode.
>> For example: FILE*  fp = fopen("example.txt", "r")
>> I want to know if there is any function that takes as parameter the file pointer fp and returns the name of the file "example.txt" and the mode "r".
>> 
>
>Others have answered about the file name.
>Unless I've missed something, no answer has been given about the file-mode.
>File-mode information can be retrieved by "fstat" (or "_fstat" on 
>Windows) in <sys/stat.h>, at least under Windows this includes 
>read/write information.

I would characterize struct stat as file metadata, not file mode.

>This is not an ISO C standard function either, it belongs to POSIX instead.

In POSIX/SuS, the file status and file descriptor flags can be set and
retreived with fcntl(2).

(e.g. O_DIRECT, O_RDONLY, O_RDWR, O_WRONLY, O_EXCL, O_NOATIME, FD_CLOEXEC et alia).

[toc] | [prev] | [next] | [standalone]

#158386

On 1/15/2021 8:55 PM, Scott Lurndal wrote:
> Manfred <noname@add.invalid> writes:
>> On 1/12/2021 4:26 PM, emanuele cannizzo wrote:
>>> Let assume that I have created a pointer to a File and I opened a file in some mode.
>>> For example: FILE*  fp = fopen("example.txt", "r")
>>> I want to know if there is any function that takes as parameter the file pointer fp and returns the name of the file "example.txt" and the mode "r".
>>>
>>
>> Others have answered about the file name.
>> Unless I've missed something, no answer has been given about the file-mode.
>> File-mode information can be retrieved by "fstat" (or "_fstat" on
>> Windows) in <sys/stat.h>, at least under Windows this includes
>> read/write information.
> 
> I would characterize struct stat as file metadata, not file mode.

Sure.
On further check the st_mode member of struct stat reports file owner 
/permissions/, which include read/write permissions.
The OP is asking for mode "r", which is (part of) the file /access 
mode/, as specified at the time of open/creation. This is indeed 
returned by fcntl as you say.
Thanks.

> 
>> This is not an ISO C standard function either, it belongs to POSIX instead.
> 
> In POSIX/SuS, the file status and file descriptor flags can be set and
> retreived with fcntl(2).
> 
> (e.g. O_DIRECT, O_RDONLY, O_RDWR, O_WRONLY, O_EXCL, O_NOATIME, FD_CLOEXEC et alia).
> 

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web