Re: readdir() on a sysopen() handle?

I am confused as to what application behavior you are trying to prevent and exactly what your application is?

A file system is like a continually evolving biological organism. There can be incestuous liaisons between family groups (symlinks).

The directory structure correlates "textual names" to "structures of bits" which are called "files".

When you do something like a readdir(), you get an imperfect snapshot of the "family tree" of textual names. It is completely possible to get a filename from a readdir() which can't be opened because it doesn't exist anymore once you actually try to open that textual name because some other process has deleted that name in the meantime.

Depending upon the O/S and the type of file, it is possible to read a directory (which produces textual names), open a file (which resolves to a binary filehandle (independent of the text name)), and continue to use that file while the textual name is deleted from the directory. That situation means that one or many programs continue to use the "file" although no new program can open it because its "textual name" no longer exists.

If you get to a file and actually open that file via a symlink, that file is open for use, even if the symlink is deleted (textual representation is deleted).

I like the first post by Laurent_R. If you don't want to follow a directory symlink, don't open it if it is one. I guess you can check if that directory name is still not a symlink once you open it, but all sorts of strange thinks can still happen.

It would be helpful if you explained a bit more about what your applications does and how it handles failed directory or file "opens".

Comment on Re: readdir() on a sysopen() handle?

Replies are listed 'Best First'.
Re^2: readdir() on a sysopen() handle? by perlhuhn (Novice) on Aug 21, 2017 at 15:33 UTC
The purpose of the program is to write data files into a specific subdirectory of the users' home directories, e.g. /home/username/datadir/datafile.timestamp.txt. datadir is only writable by the program and readable by the user. But since it's inside the user's home directory the user could rename it an replace it with a symlink or re-create it and put a symlink with the datafile name inside. Of course, the obvious solution is to change the filesystem layout but that is currently not an option. So the program needs to open the directory and the data file with O_NOFOLLOW to avoid writing to the wrong places. The desired behavior when encountering a symlink is to refuse writing the data and produce a warning message. This case is rare enough that it's not too much hassle. The readdir() part is just a minor issue and it might get removed in the future but it feels a bit clumsy right now. And since fdopendir() is part of POSIX.1-2008 one might hope to find it in a current Perl version. Anyway, thanks for all your replies. I guess I'll put up with the chdir() solution.	[reply]

Replies are listed 'Best First'.

Re^2: readdir() on a sysopen() handle?
by perlhuhn (Novice) on Aug 21, 2017 at 15:33 UTC

The purpose of the program is to write data files into a specific subdirectory of the users' home directories, e.g. /home/username/datadir/datafile.timestamp.txt.

datadir is only writable by the program and readable by the user. But since it's inside the user's home directory the user could rename it an replace it with a symlink or re-create it and put a symlink with the datafile name inside.

Of course, the obvious solution is to change the filesystem layout but that is currently not an option. So the program needs to open the directory and the data file with O_NOFOLLOW to avoid writing to the wrong places.

The desired behavior when encountering a symlink is to refuse writing the data and produce a warning message. This case is rare enough that it's not too much hassle.

The readdir() part is just a minor issue and it might get removed in the future but it feels a bit clumsy right now. And since fdopendir() is part of POSIX.1-2008 one might hope to find it in a current Perl version.

Anyway, thanks for all your replies. I guess I'll put up with the chdir() solution.

[reply]