| |
 |
|
| Linux Forum Index » Linux Development - System » strange thing after moving a directory... |
|
Page 1 of 1 |
|
| Author |
Message |
| ... |
 Posted: Fri Nov 06, 2009 3:18 pm |
|
|
|
Guest
|
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 in all cases is BASH version 3.1.17.
The Linux kernel is 2.6.26.2 which I compiled with gcc 4.1.2.
The filesystem is ReiserFS.
The machine is i686 Intel(R) Core(TM)2 Quad CPU Q6700 at (no spam) 2.66GHz GenuineIntel
Is this some weird artifact of the shell that can just sometimes happen?
Do I have some kernel corruption (this machine does not have ECC memory)?
Do I have file system corruption?
Any idea what happened?
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
----------------------------------------------------------------------------- |
|
|
| Back to top |
|
|
|
| Robert Nichols... |
| Posted: Sat Nov 07, 2009 6:24 am |
|
|
|
Guest
|
In article <hd20ah01mu1 at (no spam) news5.newsguy.com>, <phil-news-nospam at (no spam) 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
 f 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" |
|
|
| Back to top |
|
|
|
|
|
All times are GMT - 5 Hours
The time now is Mon Nov 23, 2009 1:35 am
|
|