Glenn, I do not thing this will work reliable, since <dev,ino> pairs
may not be reliable if dev and ino are 32bit and creation of
destruction of files causes a an overflow after 2^31 files, since we
can only rely on ino per file system, while dev is to identify the
file system.
This may happen very, very fast on modern machines: time /bin/ksh -c
'builtin rm ; integer i j; for ((i=0 , j=pow(2,24) ; i < j ; i++)) ;
do printf "foo\n" >xxx ; rm xxx ; done' returns in 244 seconds on
Linux/Vmware, and doing that with 256 workers process in parallel will
thus quickly exhaust a 32bit ino space.
Olga
On Thu, Aug 16, 2012 at 3:14 AM, Glenn Fowler <g...@research.att.com> wrote:
>
> I meant to track open(O_search) fds by keep in cdt indexed by <dev,ino>
> and returning the corresponding path -- then openat(fd, ...) will
> convert fd to <dev,ino> and the look up the path in the cdt
> if not in the cdt then it would use the pwd algorithm to determine
> a path and add it to the cdt -- a problem would be knowing when to
> purge the cdt -- not really workable but maybe as a last resort
>
> On Thu, 16 Aug 2012 02:18:08 +0200 =?KOI8-R?B?z8zYx8Egy9LZ1sHOz9fTy8HR?=
> wrote:
>> Glenn, I think the only portable way is to do a open(".", O_RDONLY),
>> and if that fails save the name from getcwd(), and restore that, if
>> neither /dev/fd or /proc/${pid}/fd/${dirfd} are working. As far as I
>> know there is no way to open a file using <dev,ino>, and <dev,ino> may
>> not be reliable for all kinds of file systems, such like as fuse
>> (http://en.wikipedia.org/wiki/Filesystem_in_Userspace).
>
>> Olga
>
>> On Thu, Aug 16, 2012 at 1:24 AM, ольга крыжановская
>> <olga.kryzhanov...@gmail.com> wrote:
>> > Glenn, how to an application obtain a fd just using <dev,ino>?
>> >
>> > The alternative, if no /proc or /dev/fd is available, is to save the
>> > cwd, do a temporary cwd using fchdir(), and restore the old cwd. This
>> > is now glibc did it, with a mutex around the whole sequence to make it
>> > thread safe.
>> >
>> > Olga
>> >
>> > On Thu, Aug 16, 2012 at 1:20 AM, Glenn Fowler <g...@research.att.com>
>> > wrote:
>> >>
>> >> On Thu, 16 Aug 2012 01:09:29 +0200 =?KOI8-R?B?z8zYx8Egy9LZ1sHOz9fTy8HR?=
>> >> wrote:
>> >>> Glenn, have you ever considered putting an openat(), fstatat(),
>> >>> mkfifoat() emulation into libast, if the base operating system does
>> >>> not have such calls? I have been trying more tests with the at() apis
>> >>> but I am not happy to trash much of libshell with lots of #ifdef
>> >>> AT_CWD tests if there is a better option.
>> >>
>> >>> AFAIK a lot of the at() calls can be emulated by using
>> >>> /dev/fd/${dirfd}/${path} or /proc/${pid}/fd/${dirfd}/${path}. I just
>> >>> do not know, are there cases where /dev/fd or /proc/${pid}/fd are not
>> >>> available (chroot environments?)?
>> >>
>> >> there are a lot of systems with lame or no /proc
>> >> and it will be hard to work around systems with no O_search
>> >>
>> >> but let me think a bit on that
>> >> if we didn't have to worry about dir fd's across exec (probably rare
>> >> right now)
>> >> we might be able to cache emulated open(O_search) paths with <dev,ino>
>> >> keys
>> >> on systems that don't support /dev/fd/<FD>/<PATH> pr
>> >> /proc/<PID>/fd/<FD>/<PATH>
>> >>> Olga
>> >>> --
>> >>> , _ _ ,
>> >>> { \/`o;====- Olga Kryzhanovska -====;o`\/ }
>> >>> .----'-/`-/ olga.kryzhanov...@gmail.com \-`\-'----.
>> >>> `'-..-| / http://twitter.com/fleyta \ |-..-'`
>> >>> /\/\ Solaris/BSD//C/C++ programmer /\/\
>> >>> `--` `--`
>> >>
>> >
>> >
>> >
>> > --
>> > , _ _ ,
>> > { \/`o;====- Olga Kryzhanovska -====;o`\/ }
>> > .----'-/`-/ olga.kryzhanov...@gmail.com \-`\-'----.
>> > `'-..-| / http://twitter.com/fleyta \ |-..-'`
>> > /\/\ Solaris/BSD//C/C++ programmer /\/\
>> > `--` `--`
>
>> --
>> , _ _ ,
>> { \/`o;====- Olga Kryzhanovska -====;o`\/ }
>> .----'-/`-/ olga.kryzhanov...@gmail.com \-`\-'----.
>> `'-..-| / http://twitter.com/fleyta \ |-..-'`
>> /\/\ Solaris/BSD//C/C++ programmer /\/\
>> `--` `--`
>
--
, _ _ ,
{ \/`o;====- Olga Kryzhanovska -====;o`\/ }
.----'-/`-/ olga.kryzhanov...@gmail.com \-`\-'----.
`'-..-| / http://twitter.com/fleyta \ |-..-'`
/\/\ Solaris/BSD//C/C++ programmer /\/\
`--` `--`
_______________________________________________
ast-developers mailing list
ast-developers@research.att.com
https://mailman.research.att.com/mailman/listinfo/ast-developers
