[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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


Reply to: