Re: stat() and its consequences (was: Re: Strange behavior while copying files)
Igor Khavkine <i_khavki@alcor.concordia.ca> writes:
> 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.
How does lstat work in this respect? I think symbolic links and
translators can be treated quite similarly. I.e. cp --no-dereference
(which is implied by cp -a) should copy the translator setting, and
any underlying file, but not start 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.
I would expect for instance ls -F to use lstat rather than stat, but
I'm not sure that is how it works.
> 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.
To me this seems like two bugs:
1. cp -a needs to be anhanced to know about translators.
2. The translators created files in / when started. IIRC,
translators should be started with a current directory which is
the place where they were installed in the file system. Creating
files with non-relative names from a translator doesn't seem like
a bad thing to be doing (although there certainly are some
exceptions).
/Niels
Reply to: