Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Can the transformation of a path A/./B into A/B change the meaning of the path?

I am aware that the path A/foo/../B may not refer to the same object as A/B, due to symbolic links (if foo is a symlink, then A/foo/.. may not be the same object as A). I would like to check that there are no similar dangers with A/./B

share|improve this question
    
I would think that readlink -f /any/path/with/or/without/symlinks always works best. –  Stefan Seidel Sep 20 '12 at 18:47
    
@StefanSeidel: The question is about safe manipulation of paths as strings (i.e., without accessing the file-system). –  John Bartholomew Sep 20 '12 at 18:52
    
By definition, . always refers to the current directory. It comes in handy occasionally in specific circumstances, but is usually redundant. –  Synetech Sep 20 '12 at 19:02

1 Answer 1

up vote 2 down vote accepted

In theory, . is not guaranteed to be the current directory, just as .. is not guaranteed to be the parent directory.  However, if they aren’t, you have either filesystem corruption (in which case all bets are off) or very high wizardry, which you are not likely to encounter in real life.  I’d say it’s safe to remove the ‘.’ components.

share|improve this answer
    
What kind of wizardry would affect the . == current directory? I know how symlinks can affect .. but I would have thought . to be quite robust. Could you please post a link? –  terdon Sep 20 '12 at 23:20
2  
In Windows, I believe . and .. are pseudo-entries that DIR displays and CD (and other pathname resolution services) honor. In Unix, they are actual entries in the directory. If you say rm foo, rm checks whether foo is a directory and refuses to continue if it is (unless you have specified -r). You could write a version of rm that didn't do that test. Then, if you were root, you could rm . and ln /some/other/directory .. Or at least it worked that way years ago; it may have changed; I haven't tried it recently. Warning: This is more dangerous than regedit! –  Scott Sep 20 '12 at 23:44
    
@terdon: Oh, also, a privileged user could run a hex editor on an unmounted file system disk; e.g., db /dev/hda2. –  Scott Sep 24 '12 at 22:13

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.