Quoting Tristan Wibberley :
Why
===
A common idiom on Linux is to open a file and keep the fd open so that
the underlying file can be unlinked from its directory. But if the file
needs to be read from several different parts of the codebase then due to
the file descriptor having exactly one rea
On Sun, Dec 09, 2012 at 01:37:33PM -0600, Chris Adams wrote:
> Once upon a time, Tristan Wibberley said:
> >A common idiom on Linux is to open a file and keep the fd open so that
> >the underlying file can be unlinked from its directory. But if the file
> >needs to be read from several differen
Once upon a time, Tristan Wibberley said:
>A common idiom on Linux is to open a file and keep the fd open so that
>the underlying file can be unlinked from its directory. But if the file
>needs to be read from several different parts of the codebase then due to
>the file descriptor having exac
On Sun, 09 Dec 2012 11:27:46 -0500, Theodore Ts'o wrote:
> On Sun, Dec 09, 2012 at 03:03:30PM +, Tristan Wibberley wrote:
>>
>> - /proc/self/fd/* does not solve this problem because the file might no
...
> Actually, /proc/self/fd/* _will_ work. When you do a ls -l, it looks
> like a symlin
On Sun, Dec 09, 2012 at 03:03:30PM +, Tristan Wibberley wrote:
>
> - /proc/self/fd/* does not solve this problem because the file might no
> longer be available at the same place in the filesystem. In some
> otherwise simple message passing or ReSTful IPC a different file will
> be avail
Hello,
I'd like to propose a system call called "fdreopen":
int fdreopen(int src_fd, int dst_fd, int flags);
I am willing to try implementing this system call given some suggestions
where to start and what locking to watch out for. I have given a brief of
the behaviour below, and a descript
6 matches
Mail list logo
