Path: csiph.com!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Finding the name of a file Date: Tue, 12 Jan 2021 15:12:58 -0800 Organization: None to speak of Lines: 83 Message-ID: <87eeip696t.fsf@nosuchdomain.example.com> References: <0fca7756-4bc1-4972-83a2-ee108a4e6ab2n@googlegroups.com> <1bpn2ayun0.fsf@pfeifferfamily.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: reader02.eternal-september.org; posting-host="44c21a053cd8061d43e5f4bc0ef4e13e"; logging-data="4762"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19RF+BxS9Haue42dcowYNNJ" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Cancel-Lock: sha1:kRSEmPMVOHjsmoS9Ebsux45Jou8= sha1:XMGKGIEWAA21FpaQJCzACXt+q8Y= Xref: csiph.com comp.lang.c:158328 antispam@math.uni.wroc.pl writes: > Bart wrote: >> On 12/01/2021 20:12, antispam@math.uni.wroc.pl wrote: >> > Bart wrote: >> >> On 12/01/2021 16:42, Joe Pfeiffer wrote: >> >>> emanuele cannizzo 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 */