Why does '/' contain '..'? [duplicate]Why does '/' have an '..' entry?Difference between ls command options:`ls -a` `ls -al` `ls -all`Why does '/' have an '..' entry?Why is iwconfig in /sbin?Why the unix bin directory named in that way?Why can I only run a .sh file from the parent directory, not the child directoryWhat filesystem mount point am I currently working on?What is the reasoning/design choice behind the unix/linux file system structure?Standard environment variables for distribution-specific pathsWhy is /bin a symbolic link to /usr/bin?The content of directory /dev/fd have difference file in one time

Why would a berry have a slow-acting poison?

How to pass Collection of exceptions as a root cause?

Who is Gail Gasram?

How can medieval knights protect themselves against modern guns?

Unexpected linebreak with makebox

How to save custom label as parameter for a custom entity_reference field widget?

Why does E7 sharp 9 have a G?

Contacted by head of school regarding an issue - should I be worried?

How does "unlimited holidays" in practice work?

Do I even like doing research?

How often are there lunar eclipses on Jupiter

Do Klingons have escape pods?

I can't understand how probability makes sense

What will happen to a ball kept on a frictionless inclined plane?

Why do HK chefs use a white cloth to clutch wok?

Why is it runway "1" instead of "01" in America?

Is it necessary to wipe out vile man-eating dragons?

What is the quickest way to raise Affection?

How can I obtain a Cauchy distribution from two standard normal distributions?

Suppose I capture encrypted data that I want to decrypt. Could I use a server farm to decrypt?

Guard packadd to not load an optional non-existent package

Why should I invest so much in 401(k)?

Was Nixon right, and if so, to what degree was he right, when he said that "... but when the president does it, that means that it is not illegal."?

Help me pair my socks



Why does '/' contain '..'? [duplicate]


Why does '/' have an '..' entry?Difference between ls command options:`ls -a` `ls -al` `ls -all`Why does '/' have an '..' entry?Why is iwconfig in /sbin?Why the unix bin directory named in that way?Why can I only run a .sh file from the parent directory, not the child directoryWhat filesystem mount point am I currently working on?What is the reasoning/design choice behind the unix/linux file system structure?Standard environment variables for distribution-specific pathsWhy is /bin a symbolic link to /usr/bin?The content of directory /dev/fd have difference file in one time






.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty
margin-bottom:0;









24



















This question already has an answer here:



  • Why does '/' have an '..' entry?

    2 answers



There's no directory above /, so what's the point of the .. in it?










share|improve this question















marked as duplicate by muru, Dmitry Grigoryev, Community Sep 16 at 14:45


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.














  • 1





    How do you know there's nothing above it? You may be in a chroot. Should the .. entry need to be created if you mount your root directory someplace else (like on another machine)?

    – Kusalananda
    Sep 14 at 21:17







  • 3





    Not sure this is correct but it seems like it would be more work to omit it than it would be to just apply to all directories without prejudice.

    – Jesse_b
    Sep 14 at 21:17







  • 8





    @Kusalananda cd .. in a root dir of chroot won't get you out of the chroot, nor will it fail with an error.

    – mosvy
    Sep 14 at 21:39






  • 6





    I look at it this way: consistency with the rest of the filesystem and stopping point for iterative traversal up the tree. When the parent node in a tree points to itself, you know you've reached the root of the tree.

    – Sergiy Kolodyazhnyy
    Sep 14 at 22:19






  • 2





    @Ben No advantage implied. It's just one way out of multiple how linked lists and trees may be implemented. It just happens Linux and most filesystems implement it this way, and as Kusalananda's answer points out it is open for implementation

    – Sergiy Kolodyazhnyy
    Sep 16 at 3:19

















24



















This question already has an answer here:



  • Why does '/' have an '..' entry?

    2 answers



There's no directory above /, so what's the point of the .. in it?










share|improve this question















marked as duplicate by muru, Dmitry Grigoryev, Community Sep 16 at 14:45


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.














  • 1





    How do you know there's nothing above it? You may be in a chroot. Should the .. entry need to be created if you mount your root directory someplace else (like on another machine)?

    – Kusalananda
    Sep 14 at 21:17







  • 3





    Not sure this is correct but it seems like it would be more work to omit it than it would be to just apply to all directories without prejudice.

    – Jesse_b
    Sep 14 at 21:17







  • 8





    @Kusalananda cd .. in a root dir of chroot won't get you out of the chroot, nor will it fail with an error.

    – mosvy
    Sep 14 at 21:39






  • 6





    I look at it this way: consistency with the rest of the filesystem and stopping point for iterative traversal up the tree. When the parent node in a tree points to itself, you know you've reached the root of the tree.

    – Sergiy Kolodyazhnyy
    Sep 14 at 22:19






  • 2





    @Ben No advantage implied. It's just one way out of multiple how linked lists and trees may be implemented. It just happens Linux and most filesystems implement it this way, and as Kusalananda's answer points out it is open for implementation

    – Sergiy Kolodyazhnyy
    Sep 16 at 3:19













24













24









24









This question already has an answer here:



  • Why does '/' have an '..' entry?

    2 answers



There's no directory above /, so what's the point of the .. in it?










share|improve this question















This question already has an answer here:



  • Why does '/' have an '..' entry?

    2 answers



There's no directory above /, so what's the point of the .. in it?





This question already has an answer here:



  • Why does '/' have an '..' entry?

    2 answers







filesystems directory-structure






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Sep 14 at 21:13









EmmaVEmmaV

2,7971 gold badge15 silver badges42 bronze badges




2,7971 gold badge15 silver badges42 bronze badges





marked as duplicate by muru, Dmitry Grigoryev, Community Sep 16 at 14:45


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.











marked as duplicate by muru, Dmitry Grigoryev, Community Sep 16 at 14:45


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.









marked as duplicate by muru, Dmitry Grigoryev, Community Sep 16 at 14:45


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.









  • 1





    How do you know there's nothing above it? You may be in a chroot. Should the .. entry need to be created if you mount your root directory someplace else (like on another machine)?

    – Kusalananda
    Sep 14 at 21:17







  • 3





    Not sure this is correct but it seems like it would be more work to omit it than it would be to just apply to all directories without prejudice.

    – Jesse_b
    Sep 14 at 21:17







  • 8





    @Kusalananda cd .. in a root dir of chroot won't get you out of the chroot, nor will it fail with an error.

    – mosvy
    Sep 14 at 21:39






  • 6





    I look at it this way: consistency with the rest of the filesystem and stopping point for iterative traversal up the tree. When the parent node in a tree points to itself, you know you've reached the root of the tree.

    – Sergiy Kolodyazhnyy
    Sep 14 at 22:19






  • 2





    @Ben No advantage implied. It's just one way out of multiple how linked lists and trees may be implemented. It just happens Linux and most filesystems implement it this way, and as Kusalananda's answer points out it is open for implementation

    – Sergiy Kolodyazhnyy
    Sep 16 at 3:19












  • 1





    How do you know there's nothing above it? You may be in a chroot. Should the .. entry need to be created if you mount your root directory someplace else (like on another machine)?

    – Kusalananda
    Sep 14 at 21:17







  • 3





    Not sure this is correct but it seems like it would be more work to omit it than it would be to just apply to all directories without prejudice.

    – Jesse_b
    Sep 14 at 21:17







  • 8





    @Kusalananda cd .. in a root dir of chroot won't get you out of the chroot, nor will it fail with an error.

    – mosvy
    Sep 14 at 21:39






  • 6





    I look at it this way: consistency with the rest of the filesystem and stopping point for iterative traversal up the tree. When the parent node in a tree points to itself, you know you've reached the root of the tree.

    – Sergiy Kolodyazhnyy
    Sep 14 at 22:19






  • 2





    @Ben No advantage implied. It's just one way out of multiple how linked lists and trees may be implemented. It just happens Linux and most filesystems implement it this way, and as Kusalananda's answer points out it is open for implementation

    – Sergiy Kolodyazhnyy
    Sep 16 at 3:19







1




1





How do you know there's nothing above it? You may be in a chroot. Should the .. entry need to be created if you mount your root directory someplace else (like on another machine)?

– Kusalananda
Sep 14 at 21:17






How do you know there's nothing above it? You may be in a chroot. Should the .. entry need to be created if you mount your root directory someplace else (like on another machine)?

– Kusalananda
Sep 14 at 21:17





3




3





Not sure this is correct but it seems like it would be more work to omit it than it would be to just apply to all directories without prejudice.

– Jesse_b
Sep 14 at 21:17






Not sure this is correct but it seems like it would be more work to omit it than it would be to just apply to all directories without prejudice.

– Jesse_b
Sep 14 at 21:17





8




8





@Kusalananda cd .. in a root dir of chroot won't get you out of the chroot, nor will it fail with an error.

– mosvy
Sep 14 at 21:39





@Kusalananda cd .. in a root dir of chroot won't get you out of the chroot, nor will it fail with an error.

– mosvy
Sep 14 at 21:39




6




6





I look at it this way: consistency with the rest of the filesystem and stopping point for iterative traversal up the tree. When the parent node in a tree points to itself, you know you've reached the root of the tree.

– Sergiy Kolodyazhnyy
Sep 14 at 22:19





I look at it this way: consistency with the rest of the filesystem and stopping point for iterative traversal up the tree. When the parent node in a tree points to itself, you know you've reached the root of the tree.

– Sergiy Kolodyazhnyy
Sep 14 at 22:19




2




2





@Ben No advantage implied. It's just one way out of multiple how linked lists and trees may be implemented. It just happens Linux and most filesystems implement it this way, and as Kusalananda's answer points out it is open for implementation

– Sergiy Kolodyazhnyy
Sep 16 at 3:19





@Ben No advantage implied. It's just one way out of multiple how linked lists and trees may be implemented. It just happens Linux and most filesystems implement it this way, and as Kusalananda's answer points out it is open for implementation

– Sergiy Kolodyazhnyy
Sep 16 at 3:19










4 Answers
4






active

oldest

votes


















32



















The .. entry in the root directory is a special case.



From the POSIX standard (4.13 Pathname Resolution, where the . and .. entries are referred to as "dot" and "dot-dot" repsectively):




The special filename dot shall refer to the directory specified by its predecessor. The special filename dot-dot shall refer to the parent directory of its predecessor directory. As a special case, in the root directory, dot-dot may refer to the root directory itself.




The rationale has this to add (A.4.13 Pathname Resolution)




What the filename dot-dot refers to relative to the root directory is implementation-defined. In Version 7 it refers to the root directory itself; this is the behavior mentioned in POSIX.1-2017. In some networked systems the construction /../hostname/ is used to refer to the root directory of another host, and POSIX.1 permits this behavior.



Other networked systems use the construct //hostname for the same purpose; that is, a double initial <slash> is used. [...]




So, in short, the POSIX standard says that every directory should have both . and .. entries, and permits the .. directory entry in / to refer to the / directory itself (notice the word "may" in the first text quoted), but it also allows an implementation to let it refer to something else.



Most common implementations of filesystems makes /.. resolve to /.






share|improve this answer























  • 5





    In other words, POSIX says "A POSIX compliant system must have /.. but it's up to you what you want to do with it"

    – Sergiy Kolodyazhnyy
    Sep 14 at 22:24











  • @SergiyKolodyazhnyy Pretty much, yes, if by "you" you mean someone implementing the standard.

    – Kusalananda
    Sep 14 at 22:25


















17



















Kusalananda has already told you that this is the behavior specified by the POSIX standard. However, the history of UNIX began in earnest in the early 1970s. POSIX dates back only to the second half of the 1980s, a full decade and a half later. In practice, POSIX merely specified what was already being done by implementations.



Rather, UNIX did very early on support mounting file systems on different devices into its single unified directory hierarchy. Each file system, in effect, has its own root directory; the file system mounted at / isn't particularly special in any way. (Its contents might be, but the file system itself isn't.)



The sysmount and sysumount system calls appear to have been introduced in UNIX V1, in 1970-1971 (V1 is dated 1971-11, according to the Unix Tree at The Unix Heritage Society). They are defined in u1.s (system call numbers 21 and 22, respectively) and implemented in u7.s. (PDP7 UNIX, dated 1970-01, does not appear to have any obvious ancestor of those).



You probably see where this is going: when any file system can be mounted at any location in the hierarchy, to keep from having to special-case things, each directory, including the root directory of each file system, should contain an entry pointing to its own parent directory. On disk, the logical place to point a file system's root directory's parent directory entry at is the file system's root directory, because there is nothing else "above" the file system's root directory. The concept of having something "above" the root directory only comes into play when that file system is mounted at some location other than the root of the hierarchy.



During mounting, it is possible to rewrite the "parent directory" pointer in the memory copy of the root directory to point at the parent directory of the mount point directory. If there is no parent directory of the mount point directory (in other words, the file system is being mounted as /), then just leave that piece of data alone (because there's likely nowhere else sensible to point it to anyway) or handle it separately later (as would probably be the case for the /../hostname/path and //hostname/path cases mentioned in Kusalananda's answer).



The resulting behavior is that in any directory other than /, regardless of whether it's a particular file system's root directory or a subdirectory (at any level of nesting), .. points at that directory's parent directory; and in /, .. points back at /. The former is what would feel natural (.. always works in the same way, moving you one step toward the root directory), while the latter, while slightly idiosyncratic, at least doesn't obviously break anything (there's little harm in not being able to move further toward the root directory than to the root directory itself). For example, you can hammer out an arbitrary number of ../ and know that those at least will not cause an error because .. at some point does not exist.






share|improve this answer

































    2



















    There is a directory above /, / itself. The parent directory of the root directory is itself. cd .. or cd ../.. inside the root directory should leave you at the same place, not cause an error.



    Notice that neither . or .. may exist as actual directory entries in some filesystems, they may be simply emulated by the virtual file system layer of the OS.




    A path like /../hostname is supposed to have let you access the root of another host in some early pre-vfs and pre-nfs systems like MUNIX (using the "Newcastle Connection") but I don't know of any such system still in use, and the source code is nowhere to be found.



    The available info is highly contradictory, but it seems that the most usual way to deploy such a system was by recompiling all programs so that all path-using calls like open(2) could be redirected in userspace (there were no shared libs in that time).



    There were probably hundreds of such hacks (scratchbox being a more recent one that I had the displeasure of having to use), so it's not at all clear why they felt the need to accomodate it in the POSIX standard.






    share|improve this answer



































      1



















      Beyond all other reasons mentioned here it is design simplicity, something for which UNIX is known. All directories contain ..; special cases are always tripping hazards (for security or robustness) looming in the dark. So instead of forcing programmers to deal with one rare case in many places, all directories are designed to have . and .. entries and are dealt with uniformly, and consideration of what happens at / is not needed.






      share|improve this answer

































        4 Answers
        4






        active

        oldest

        votes








        4 Answers
        4






        active

        oldest

        votes









        active

        oldest

        votes






        active

        oldest

        votes









        32



















        The .. entry in the root directory is a special case.



        From the POSIX standard (4.13 Pathname Resolution, where the . and .. entries are referred to as "dot" and "dot-dot" repsectively):




        The special filename dot shall refer to the directory specified by its predecessor. The special filename dot-dot shall refer to the parent directory of its predecessor directory. As a special case, in the root directory, dot-dot may refer to the root directory itself.




        The rationale has this to add (A.4.13 Pathname Resolution)




        What the filename dot-dot refers to relative to the root directory is implementation-defined. In Version 7 it refers to the root directory itself; this is the behavior mentioned in POSIX.1-2017. In some networked systems the construction /../hostname/ is used to refer to the root directory of another host, and POSIX.1 permits this behavior.



        Other networked systems use the construct //hostname for the same purpose; that is, a double initial <slash> is used. [...]




        So, in short, the POSIX standard says that every directory should have both . and .. entries, and permits the .. directory entry in / to refer to the / directory itself (notice the word "may" in the first text quoted), but it also allows an implementation to let it refer to something else.



        Most common implementations of filesystems makes /.. resolve to /.






        share|improve this answer























        • 5





          In other words, POSIX says "A POSIX compliant system must have /.. but it's up to you what you want to do with it"

          – Sergiy Kolodyazhnyy
          Sep 14 at 22:24











        • @SergiyKolodyazhnyy Pretty much, yes, if by "you" you mean someone implementing the standard.

          – Kusalananda
          Sep 14 at 22:25















        32



















        The .. entry in the root directory is a special case.



        From the POSIX standard (4.13 Pathname Resolution, where the . and .. entries are referred to as "dot" and "dot-dot" repsectively):




        The special filename dot shall refer to the directory specified by its predecessor. The special filename dot-dot shall refer to the parent directory of its predecessor directory. As a special case, in the root directory, dot-dot may refer to the root directory itself.




        The rationale has this to add (A.4.13 Pathname Resolution)




        What the filename dot-dot refers to relative to the root directory is implementation-defined. In Version 7 it refers to the root directory itself; this is the behavior mentioned in POSIX.1-2017. In some networked systems the construction /../hostname/ is used to refer to the root directory of another host, and POSIX.1 permits this behavior.



        Other networked systems use the construct //hostname for the same purpose; that is, a double initial <slash> is used. [...]




        So, in short, the POSIX standard says that every directory should have both . and .. entries, and permits the .. directory entry in / to refer to the / directory itself (notice the word "may" in the first text quoted), but it also allows an implementation to let it refer to something else.



        Most common implementations of filesystems makes /.. resolve to /.






        share|improve this answer























        • 5





          In other words, POSIX says "A POSIX compliant system must have /.. but it's up to you what you want to do with it"

          – Sergiy Kolodyazhnyy
          Sep 14 at 22:24











        • @SergiyKolodyazhnyy Pretty much, yes, if by "you" you mean someone implementing the standard.

          – Kusalananda
          Sep 14 at 22:25













        32















        32











        32









        The .. entry in the root directory is a special case.



        From the POSIX standard (4.13 Pathname Resolution, where the . and .. entries are referred to as "dot" and "dot-dot" repsectively):




        The special filename dot shall refer to the directory specified by its predecessor. The special filename dot-dot shall refer to the parent directory of its predecessor directory. As a special case, in the root directory, dot-dot may refer to the root directory itself.




        The rationale has this to add (A.4.13 Pathname Resolution)




        What the filename dot-dot refers to relative to the root directory is implementation-defined. In Version 7 it refers to the root directory itself; this is the behavior mentioned in POSIX.1-2017. In some networked systems the construction /../hostname/ is used to refer to the root directory of another host, and POSIX.1 permits this behavior.



        Other networked systems use the construct //hostname for the same purpose; that is, a double initial <slash> is used. [...]




        So, in short, the POSIX standard says that every directory should have both . and .. entries, and permits the .. directory entry in / to refer to the / directory itself (notice the word "may" in the first text quoted), but it also allows an implementation to let it refer to something else.



        Most common implementations of filesystems makes /.. resolve to /.






        share|improve this answer
















        The .. entry in the root directory is a special case.



        From the POSIX standard (4.13 Pathname Resolution, where the . and .. entries are referred to as "dot" and "dot-dot" repsectively):




        The special filename dot shall refer to the directory specified by its predecessor. The special filename dot-dot shall refer to the parent directory of its predecessor directory. As a special case, in the root directory, dot-dot may refer to the root directory itself.




        The rationale has this to add (A.4.13 Pathname Resolution)




        What the filename dot-dot refers to relative to the root directory is implementation-defined. In Version 7 it refers to the root directory itself; this is the behavior mentioned in POSIX.1-2017. In some networked systems the construction /../hostname/ is used to refer to the root directory of another host, and POSIX.1 permits this behavior.



        Other networked systems use the construct //hostname for the same purpose; that is, a double initial <slash> is used. [...]




        So, in short, the POSIX standard says that every directory should have both . and .. entries, and permits the .. directory entry in / to refer to the / directory itself (notice the word "may" in the first text quoted), but it also allows an implementation to let it refer to something else.



        Most common implementations of filesystems makes /.. resolve to /.







        share|improve this answer















        share|improve this answer




        share|improve this answer








        edited Sep 15 at 15:40

























        answered Sep 14 at 22:19









        KusalanandaKusalananda

        173k20 gold badges330 silver badges536 bronze badges




        173k20 gold badges330 silver badges536 bronze badges










        • 5





          In other words, POSIX says "A POSIX compliant system must have /.. but it's up to you what you want to do with it"

          – Sergiy Kolodyazhnyy
          Sep 14 at 22:24











        • @SergiyKolodyazhnyy Pretty much, yes, if by "you" you mean someone implementing the standard.

          – Kusalananda
          Sep 14 at 22:25












        • 5





          In other words, POSIX says "A POSIX compliant system must have /.. but it's up to you what you want to do with it"

          – Sergiy Kolodyazhnyy
          Sep 14 at 22:24











        • @SergiyKolodyazhnyy Pretty much, yes, if by "you" you mean someone implementing the standard.

          – Kusalananda
          Sep 14 at 22:25







        5




        5





        In other words, POSIX says "A POSIX compliant system must have /.. but it's up to you what you want to do with it"

        – Sergiy Kolodyazhnyy
        Sep 14 at 22:24





        In other words, POSIX says "A POSIX compliant system must have /.. but it's up to you what you want to do with it"

        – Sergiy Kolodyazhnyy
        Sep 14 at 22:24













        @SergiyKolodyazhnyy Pretty much, yes, if by "you" you mean someone implementing the standard.

        – Kusalananda
        Sep 14 at 22:25





        @SergiyKolodyazhnyy Pretty much, yes, if by "you" you mean someone implementing the standard.

        – Kusalananda
        Sep 14 at 22:25













        17



















        Kusalananda has already told you that this is the behavior specified by the POSIX standard. However, the history of UNIX began in earnest in the early 1970s. POSIX dates back only to the second half of the 1980s, a full decade and a half later. In practice, POSIX merely specified what was already being done by implementations.



        Rather, UNIX did very early on support mounting file systems on different devices into its single unified directory hierarchy. Each file system, in effect, has its own root directory; the file system mounted at / isn't particularly special in any way. (Its contents might be, but the file system itself isn't.)



        The sysmount and sysumount system calls appear to have been introduced in UNIX V1, in 1970-1971 (V1 is dated 1971-11, according to the Unix Tree at The Unix Heritage Society). They are defined in u1.s (system call numbers 21 and 22, respectively) and implemented in u7.s. (PDP7 UNIX, dated 1970-01, does not appear to have any obvious ancestor of those).



        You probably see where this is going: when any file system can be mounted at any location in the hierarchy, to keep from having to special-case things, each directory, including the root directory of each file system, should contain an entry pointing to its own parent directory. On disk, the logical place to point a file system's root directory's parent directory entry at is the file system's root directory, because there is nothing else "above" the file system's root directory. The concept of having something "above" the root directory only comes into play when that file system is mounted at some location other than the root of the hierarchy.



        During mounting, it is possible to rewrite the "parent directory" pointer in the memory copy of the root directory to point at the parent directory of the mount point directory. If there is no parent directory of the mount point directory (in other words, the file system is being mounted as /), then just leave that piece of data alone (because there's likely nowhere else sensible to point it to anyway) or handle it separately later (as would probably be the case for the /../hostname/path and //hostname/path cases mentioned in Kusalananda's answer).



        The resulting behavior is that in any directory other than /, regardless of whether it's a particular file system's root directory or a subdirectory (at any level of nesting), .. points at that directory's parent directory; and in /, .. points back at /. The former is what would feel natural (.. always works in the same way, moving you one step toward the root directory), while the latter, while slightly idiosyncratic, at least doesn't obviously break anything (there's little harm in not being able to move further toward the root directory than to the root directory itself). For example, you can hammer out an arbitrary number of ../ and know that those at least will not cause an error because .. at some point does not exist.






        share|improve this answer






























          17



















          Kusalananda has already told you that this is the behavior specified by the POSIX standard. However, the history of UNIX began in earnest in the early 1970s. POSIX dates back only to the second half of the 1980s, a full decade and a half later. In practice, POSIX merely specified what was already being done by implementations.



          Rather, UNIX did very early on support mounting file systems on different devices into its single unified directory hierarchy. Each file system, in effect, has its own root directory; the file system mounted at / isn't particularly special in any way. (Its contents might be, but the file system itself isn't.)



          The sysmount and sysumount system calls appear to have been introduced in UNIX V1, in 1970-1971 (V1 is dated 1971-11, according to the Unix Tree at The Unix Heritage Society). They are defined in u1.s (system call numbers 21 and 22, respectively) and implemented in u7.s. (PDP7 UNIX, dated 1970-01, does not appear to have any obvious ancestor of those).



          You probably see where this is going: when any file system can be mounted at any location in the hierarchy, to keep from having to special-case things, each directory, including the root directory of each file system, should contain an entry pointing to its own parent directory. On disk, the logical place to point a file system's root directory's parent directory entry at is the file system's root directory, because there is nothing else "above" the file system's root directory. The concept of having something "above" the root directory only comes into play when that file system is mounted at some location other than the root of the hierarchy.



          During mounting, it is possible to rewrite the "parent directory" pointer in the memory copy of the root directory to point at the parent directory of the mount point directory. If there is no parent directory of the mount point directory (in other words, the file system is being mounted as /), then just leave that piece of data alone (because there's likely nowhere else sensible to point it to anyway) or handle it separately later (as would probably be the case for the /../hostname/path and //hostname/path cases mentioned in Kusalananda's answer).



          The resulting behavior is that in any directory other than /, regardless of whether it's a particular file system's root directory or a subdirectory (at any level of nesting), .. points at that directory's parent directory; and in /, .. points back at /. The former is what would feel natural (.. always works in the same way, moving you one step toward the root directory), while the latter, while slightly idiosyncratic, at least doesn't obviously break anything (there's little harm in not being able to move further toward the root directory than to the root directory itself). For example, you can hammer out an arbitrary number of ../ and know that those at least will not cause an error because .. at some point does not exist.






          share|improve this answer




























            17















            17











            17









            Kusalananda has already told you that this is the behavior specified by the POSIX standard. However, the history of UNIX began in earnest in the early 1970s. POSIX dates back only to the second half of the 1980s, a full decade and a half later. In practice, POSIX merely specified what was already being done by implementations.



            Rather, UNIX did very early on support mounting file systems on different devices into its single unified directory hierarchy. Each file system, in effect, has its own root directory; the file system mounted at / isn't particularly special in any way. (Its contents might be, but the file system itself isn't.)



            The sysmount and sysumount system calls appear to have been introduced in UNIX V1, in 1970-1971 (V1 is dated 1971-11, according to the Unix Tree at The Unix Heritage Society). They are defined in u1.s (system call numbers 21 and 22, respectively) and implemented in u7.s. (PDP7 UNIX, dated 1970-01, does not appear to have any obvious ancestor of those).



            You probably see where this is going: when any file system can be mounted at any location in the hierarchy, to keep from having to special-case things, each directory, including the root directory of each file system, should contain an entry pointing to its own parent directory. On disk, the logical place to point a file system's root directory's parent directory entry at is the file system's root directory, because there is nothing else "above" the file system's root directory. The concept of having something "above" the root directory only comes into play when that file system is mounted at some location other than the root of the hierarchy.



            During mounting, it is possible to rewrite the "parent directory" pointer in the memory copy of the root directory to point at the parent directory of the mount point directory. If there is no parent directory of the mount point directory (in other words, the file system is being mounted as /), then just leave that piece of data alone (because there's likely nowhere else sensible to point it to anyway) or handle it separately later (as would probably be the case for the /../hostname/path and //hostname/path cases mentioned in Kusalananda's answer).



            The resulting behavior is that in any directory other than /, regardless of whether it's a particular file system's root directory or a subdirectory (at any level of nesting), .. points at that directory's parent directory; and in /, .. points back at /. The former is what would feel natural (.. always works in the same way, moving you one step toward the root directory), while the latter, while slightly idiosyncratic, at least doesn't obviously break anything (there's little harm in not being able to move further toward the root directory than to the root directory itself). For example, you can hammer out an arbitrary number of ../ and know that those at least will not cause an error because .. at some point does not exist.






            share|improve this answer














            Kusalananda has already told you that this is the behavior specified by the POSIX standard. However, the history of UNIX began in earnest in the early 1970s. POSIX dates back only to the second half of the 1980s, a full decade and a half later. In practice, POSIX merely specified what was already being done by implementations.



            Rather, UNIX did very early on support mounting file systems on different devices into its single unified directory hierarchy. Each file system, in effect, has its own root directory; the file system mounted at / isn't particularly special in any way. (Its contents might be, but the file system itself isn't.)



            The sysmount and sysumount system calls appear to have been introduced in UNIX V1, in 1970-1971 (V1 is dated 1971-11, according to the Unix Tree at The Unix Heritage Society). They are defined in u1.s (system call numbers 21 and 22, respectively) and implemented in u7.s. (PDP7 UNIX, dated 1970-01, does not appear to have any obvious ancestor of those).



            You probably see where this is going: when any file system can be mounted at any location in the hierarchy, to keep from having to special-case things, each directory, including the root directory of each file system, should contain an entry pointing to its own parent directory. On disk, the logical place to point a file system's root directory's parent directory entry at is the file system's root directory, because there is nothing else "above" the file system's root directory. The concept of having something "above" the root directory only comes into play when that file system is mounted at some location other than the root of the hierarchy.



            During mounting, it is possible to rewrite the "parent directory" pointer in the memory copy of the root directory to point at the parent directory of the mount point directory. If there is no parent directory of the mount point directory (in other words, the file system is being mounted as /), then just leave that piece of data alone (because there's likely nowhere else sensible to point it to anyway) or handle it separately later (as would probably be the case for the /../hostname/path and //hostname/path cases mentioned in Kusalananda's answer).



            The resulting behavior is that in any directory other than /, regardless of whether it's a particular file system's root directory or a subdirectory (at any level of nesting), .. points at that directory's parent directory; and in /, .. points back at /. The former is what would feel natural (.. always works in the same way, moving you one step toward the root directory), while the latter, while slightly idiosyncratic, at least doesn't obviously break anything (there's little harm in not being able to move further toward the root directory than to the root directory itself). For example, you can hammer out an arbitrary number of ../ and know that those at least will not cause an error because .. at some point does not exist.







            share|improve this answer













            share|improve this answer




            share|improve this answer










            answered Sep 15 at 14:22









            a CVna CVn

            20.4k9 gold badges55 silver badges115 bronze badges




            20.4k9 gold badges55 silver badges115 bronze badges
























                2



















                There is a directory above /, / itself. The parent directory of the root directory is itself. cd .. or cd ../.. inside the root directory should leave you at the same place, not cause an error.



                Notice that neither . or .. may exist as actual directory entries in some filesystems, they may be simply emulated by the virtual file system layer of the OS.




                A path like /../hostname is supposed to have let you access the root of another host in some early pre-vfs and pre-nfs systems like MUNIX (using the "Newcastle Connection") but I don't know of any such system still in use, and the source code is nowhere to be found.



                The available info is highly contradictory, but it seems that the most usual way to deploy such a system was by recompiling all programs so that all path-using calls like open(2) could be redirected in userspace (there were no shared libs in that time).



                There were probably hundreds of such hacks (scratchbox being a more recent one that I had the displeasure of having to use), so it's not at all clear why they felt the need to accomodate it in the POSIX standard.






                share|improve this answer
































                  2



















                  There is a directory above /, / itself. The parent directory of the root directory is itself. cd .. or cd ../.. inside the root directory should leave you at the same place, not cause an error.



                  Notice that neither . or .. may exist as actual directory entries in some filesystems, they may be simply emulated by the virtual file system layer of the OS.




                  A path like /../hostname is supposed to have let you access the root of another host in some early pre-vfs and pre-nfs systems like MUNIX (using the "Newcastle Connection") but I don't know of any such system still in use, and the source code is nowhere to be found.



                  The available info is highly contradictory, but it seems that the most usual way to deploy such a system was by recompiling all programs so that all path-using calls like open(2) could be redirected in userspace (there were no shared libs in that time).



                  There were probably hundreds of such hacks (scratchbox being a more recent one that I had the displeasure of having to use), so it's not at all clear why they felt the need to accomodate it in the POSIX standard.






                  share|improve this answer






























                    2















                    2











                    2









                    There is a directory above /, / itself. The parent directory of the root directory is itself. cd .. or cd ../.. inside the root directory should leave you at the same place, not cause an error.



                    Notice that neither . or .. may exist as actual directory entries in some filesystems, they may be simply emulated by the virtual file system layer of the OS.




                    A path like /../hostname is supposed to have let you access the root of another host in some early pre-vfs and pre-nfs systems like MUNIX (using the "Newcastle Connection") but I don't know of any such system still in use, and the source code is nowhere to be found.



                    The available info is highly contradictory, but it seems that the most usual way to deploy such a system was by recompiling all programs so that all path-using calls like open(2) could be redirected in userspace (there were no shared libs in that time).



                    There were probably hundreds of such hacks (scratchbox being a more recent one that I had the displeasure of having to use), so it's not at all clear why they felt the need to accomodate it in the POSIX standard.






                    share|improve this answer
















                    There is a directory above /, / itself. The parent directory of the root directory is itself. cd .. or cd ../.. inside the root directory should leave you at the same place, not cause an error.



                    Notice that neither . or .. may exist as actual directory entries in some filesystems, they may be simply emulated by the virtual file system layer of the OS.




                    A path like /../hostname is supposed to have let you access the root of another host in some early pre-vfs and pre-nfs systems like MUNIX (using the "Newcastle Connection") but I don't know of any such system still in use, and the source code is nowhere to be found.



                    The available info is highly contradictory, but it seems that the most usual way to deploy such a system was by recompiling all programs so that all path-using calls like open(2) could be redirected in userspace (there were no shared libs in that time).



                    There were probably hundreds of such hacks (scratchbox being a more recent one that I had the displeasure of having to use), so it's not at all clear why they felt the need to accomodate it in the POSIX standard.







                    share|improve this answer















                    share|improve this answer




                    share|improve this answer








                    edited Sep 15 at 15:54

























                    answered Sep 14 at 21:38









                    mosvymosvy

                    18.4k2 gold badges24 silver badges56 bronze badges




                    18.4k2 gold badges24 silver badges56 bronze badges
























                        1



















                        Beyond all other reasons mentioned here it is design simplicity, something for which UNIX is known. All directories contain ..; special cases are always tripping hazards (for security or robustness) looming in the dark. So instead of forcing programmers to deal with one rare case in many places, all directories are designed to have . and .. entries and are dealt with uniformly, and consideration of what happens at / is not needed.






                        share|improve this answer






























                          1



















                          Beyond all other reasons mentioned here it is design simplicity, something for which UNIX is known. All directories contain ..; special cases are always tripping hazards (for security or robustness) looming in the dark. So instead of forcing programmers to deal with one rare case in many places, all directories are designed to have . and .. entries and are dealt with uniformly, and consideration of what happens at / is not needed.






                          share|improve this answer




























                            1















                            1











                            1









                            Beyond all other reasons mentioned here it is design simplicity, something for which UNIX is known. All directories contain ..; special cases are always tripping hazards (for security or robustness) looming in the dark. So instead of forcing programmers to deal with one rare case in many places, all directories are designed to have . and .. entries and are dealt with uniformly, and consideration of what happens at / is not needed.






                            share|improve this answer














                            Beyond all other reasons mentioned here it is design simplicity, something for which UNIX is known. All directories contain ..; special cases are always tripping hazards (for security or robustness) looming in the dark. So instead of forcing programmers to deal with one rare case in many places, all directories are designed to have . and .. entries and are dealt with uniformly, and consideration of what happens at / is not needed.







                            share|improve this answer













                            share|improve this answer




                            share|improve this answer










                            answered Sep 16 at 11:05









                            countermodecountermode

                            5,8365 gold badges22 silver badges48 bronze badges




                            5,8365 gold badges22 silver badges48 bronze badges
















                                Popular posts from this blog

                                Tamil (spriik) Luke uk diar | Nawigatjuun

                                Align equal signs while including text over equalitiesAMS align: left aligned text/math plus multicolumn alignmentMultiple alignmentsAligning equations in multiple placesNumbering and aligning an equation with multiple columnsHow to align one equation with another multline equationUsing \ in environments inside the begintabularxNumber equations and preserving alignment of equal signsHow can I align equations to the left and to the right?Double equation alignment problem within align enviromentAligned within align: Why are they right-aligned?

                                Training a classifier when some of the features are unknownWhy does Gradient Boosting regression predict negative values when there are no negative y-values in my training set?How to improve an existing (trained) classifier?What is effect when I set up some self defined predisctor variables?Why Matlab neural network classification returns decimal values on prediction dataset?Fitting and transforming text data in training, testing, and validation setsHow to quantify the performance of the classifier (multi-class SVM) using the test data?How do I control for some patients providing multiple samples in my training data?Training and Test setTraining a convolutional neural network for image denoising in MatlabShouldn't an autoencoder with #(neurons in hidden layer) = #(neurons in input layer) be “perfect”?