stat() and its consequences (was: Re: Strange behavior while copying files)
On Sat, Aug 11, 2001 at 12:38:47PM +0200, Robert Bihlmeyer wrote:
> Igor Khavkine <i_khavki@alcor.concordia.ca> writes:
>
> > The strange thing happens when this is done, if I look in my / I
> > have a ton of pty* and tty* device files created there, even though
> > I copied no files to or from /.
>
> Just to be sure: you don't have (ana)cron that maybe decided to start
> a find over a whole filesystem (Debian's /etc/cron.daily/standard will
> do that)? This would stat everything, and therefore activate
> translators.
Actually you're not far from the truth. My cron is not doing anything
funny, but cp -a stats all files in /sub/dev, which happen to have
translator settings like this:
/hurd/term /ptyp0 pty-master /ttyp0
And turns out /hurd/term creates /ptyp0 and /ttyp0 once it's run. So no
big mystery there.
This brings up a point that has been discussed here before
but I think still needs some attention. I mean the behavior of stat().
Although stat() has to wake up the underlying translator on the node
it's being passed as argument, but we should consider a supplementary
call like stat() but which does not wake up the translator. If programs
like mc, ls, cp... where changed to use this new call instead of stat
on some occasions it can eliminate some slowness and unexpected
behavior on their part.
What I expected to happen when I ran cp -a was to get verbatim copy
of one directory's contents in another. By verbatim I mean, same permissions,
same owners, same all other attributes, a symlink if the orginal file
was a symlink and and the same translator setting if it there was a
translator on the original file. All of the above are done except for
copying the same translator setting. And I was certainly not expecting
device files appearing in my / directory.
Although using stat() on a node and creating a "verbatim" copy of a file
are not directly related, it illustrates the same point. Although
the concept of translators _requires_ them to be transparent, we do not
always _want_ them to be so.
I think this topic deserves more consideration.
Igor
Reply to: