Igor Khavkine <[EMAIL PROTECTED]> 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