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


Groups > comp.lang.c > #158328

Re: Finding the name of a file

From Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups comp.lang.c
Subject Re: Finding the name of a file
Date 2021-01-12 15:12 -0800
Organization None to speak of
Message-ID <87eeip696t.fsf@nosuchdomain.example.com> (permalink)
References (1 earlier) <1bpn2ayun0.fsf@pfeifferfamily.net> <SwkLH.205335$JT57.84806@fx31.ams4> <rtkvr1$erd$2@z-news.wcss.wroc.pl> <EEnLH.205339$JT57.142931@fx31.ams4> <rtl6vf$kgg$1@z-news.wcss.wroc.pl>

Show all headers | View raw


antispam@math.uni.wroc.pl writes:
> Bart <bc@freeuk.com> wrote:
>> On 12/01/2021 20:12, antispam@math.uni.wroc.pl wrote:
>> > Bart <bc@freeuk.com> wrote:
>> >> On 12/01/2021 16:42, Joe Pfeiffer wrote:
>> >>> emanuele cannizzo <emacannizzo@gmail.com> writes:
>> >>>
>> >>>> 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".
>> >>>
>> >>> Depending on the file system a file may not even have a unique name, so
>> >>> this can be impossible even in principle (this is true of the 
>> "standard"
>> >>> file systems under Linux).
>> >>
>> >> What's wrong with just returning the name that was passed to fopen()?
>> >
>> > Depends what you want to do with the name.  If you want to pass
>> > the name to another program P2 so that P2 can access the same
>> > file, then in most cases 'proc' method is superior.
>> 
>> If the file name is relative, then the file you get may depend on the 
>> current directory etc. If that context can be different, then turn the 
>> relative file spec into an absolute one.
>> 
>> It still may not work because file names and paths may be deleted or be 
>> changed, or the file itself may be different anyway.
>> 
>> This is the same problem as opening and closing file A at one point in a 
>> program, then accessing file A again later on. It may or may not work, 
>> or yield a different file.
>
> Yes.  If you need to access "the same file", then you can try
> workarounds like trying to get canonical name.  But is
> reliable only if user can not change components of the name,
> otherwise determined malicious user still manage to change
> file pointed to by name (even when he/she can not change content
> of the file).  Or you can use reliable (but system specific)
> method.
>
>> >  Trival advantage
>> > is that 'proc' gives you access to deleted/renamed files
>> > while using original name may fail.
>> 
>> Is that an advantage? Usually you don't want a deleted file to be 
>> visible, and you want to rename file A to B so that you /can't/ access 
>> it as A.
>  
> As I wrote, it depends on what you want.  I you want "the same
> file", the 'proc' method can do this while normal names can not.
> If you want "whatever file currently happens to be under
> this name", then use normal name.
>
> Just understand that files are different than file names.
> Filesystem maps names to files.  What users perceive as
> delete breaks association between name and file (and
> operation is called 'unlink' to stress this aspect).
> But even if you unlink all normal names file exists
> as long as there are programs which keep it open.
> File is really deleted when it is not accessible trough
> filesystem and no program uses it.  This may look
> like solipsism, but in fact give you nice warranties
> of correctness.  For example, with some care you can
> replace some critical system files while system is
> running.  Simply programs started before update continue
> to use old file, the ones started after update use
> new file.  Eventually old file will be unused and
> really deleted.  No nonsense like "reboot for update
> to take effect". 

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.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

Back to comp.lang.c | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

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

csiph-web