In article <hd20ah01
...@news5.newsguy.com>, <phil-news-nos
...@ipal.net> wrote:
:I was editing some files in a subdirectory of a project (which itself is a
:subdirectory of a directory named "projects"). After concluding this edit
:I decided I wanted to have the option to revert my changes. Since this is
:not being doing in a revision management system, and instead I have backups
:of different versions, I decided to do the following steps:
:
:1. In a shell session that was not involved in previous edits, I changed
: to the "projects" directory.
:
:2. I renamed the directory for the project to bump the version number.
: These directory names have the version number appended. Now I have a
: "hole" in the directory names.
:
:3. I used rsync to copy the original directory name from a backup, thus
: filling in the "hole" with the old contents.
:
:Eight total shell sessions were in various subdirectories of the project,
:including the one I did the editing in. What I expected to happen, and what
:normally happens, is that the current directory of these shell sessions stays
:with the actual directory inode. So when I do the command "pwd" I expect to
:now be in a subdirectory of the renamed project directory. For most of the
:shell sessions that was the case. However, in two of the shell session this
:was NOT the case. These shell sessions still show as being in the old name.
:These two were NOT involved in doing any editing. What I did in these two
:shell sessions was "ld -Al" giving the name of the subdirectory that edited
:files were in, prefixed with "../". In the shell sessions that did have the
:expected (bumped) directory name, this command showed the expected files as
:having been edited. But, in the two shell sessions that did not have the
:expected directory name, at least they were consistent and showed the files
:that were edited, in their original (before editing) dates and sizes.
:
:I am assuming that somehow these two shell sessions changed directory and are
:now in the equivalent directory of the directories retrieved from the backup
:via rsync.
The shell does not know that its current working directory has been
renamed. The shell keeps its notion of the current directory in its
internal PWD variable. What you run when you just type "pwd" is a shell
builtin that just reports the value of $PWD. You would have to run
"/bin/pwd" explicitly to see the current name of your working directory.
There is a similar issue if you have reached your current directory by
traversing symlinks. Typing "pwd" shows the symlink path that the shell
recorded in $PWD, while "/bin/pwd" will show the real path.
--
Bob Nichols AT comcast.net I am "RNichols42"
|
