How fsync treats directory links?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
0
down vote

favorite












What is the meaning of the following statement from the fsync man page




Calling fsync() does not necessarily ensure that the entry in the
directory containing the file has also reached disk. For that an
explicit fsync() on a file descriptor for the directory is also
needed.




Does it mean that fsync won't update the directory metadata when I call fsync on a file?



Another quote for the same problem is(from Robert Love's Book of Linux System Programming):




Neither function guarantees that any updated directory entries
containing the file are synchronized to disk. This implies that if a
file’s link has recently been updated, the file’s data may
successfully reach the disk but not the associated directory entry,
rendering the file unreachable.




Why would a file's data need to reach a directory link ? Correct me if I am wrong but the directories only contain the filename and the inode number for that file. The actual data is in the file. What is the meaning of "the data will reach the file but not the directory link"







share|improve this question


























    up vote
    0
    down vote

    favorite












    What is the meaning of the following statement from the fsync man page




    Calling fsync() does not necessarily ensure that the entry in the
    directory containing the file has also reached disk. For that an
    explicit fsync() on a file descriptor for the directory is also
    needed.




    Does it mean that fsync won't update the directory metadata when I call fsync on a file?



    Another quote for the same problem is(from Robert Love's Book of Linux System Programming):




    Neither function guarantees that any updated directory entries
    containing the file are synchronized to disk. This implies that if a
    file’s link has recently been updated, the file’s data may
    successfully reach the disk but not the associated directory entry,
    rendering the file unreachable.




    Why would a file's data need to reach a directory link ? Correct me if I am wrong but the directories only contain the filename and the inode number for that file. The actual data is in the file. What is the meaning of "the data will reach the file but not the directory link"







    share|improve this question
























      up vote
      0
      down vote

      favorite









      up vote
      0
      down vote

      favorite











      What is the meaning of the following statement from the fsync man page




      Calling fsync() does not necessarily ensure that the entry in the
      directory containing the file has also reached disk. For that an
      explicit fsync() on a file descriptor for the directory is also
      needed.




      Does it mean that fsync won't update the directory metadata when I call fsync on a file?



      Another quote for the same problem is(from Robert Love's Book of Linux System Programming):




      Neither function guarantees that any updated directory entries
      containing the file are synchronized to disk. This implies that if a
      file’s link has recently been updated, the file’s data may
      successfully reach the disk but not the associated directory entry,
      rendering the file unreachable.




      Why would a file's data need to reach a directory link ? Correct me if I am wrong but the directories only contain the filename and the inode number for that file. The actual data is in the file. What is the meaning of "the data will reach the file but not the directory link"







      share|improve this question














      What is the meaning of the following statement from the fsync man page




      Calling fsync() does not necessarily ensure that the entry in the
      directory containing the file has also reached disk. For that an
      explicit fsync() on a file descriptor for the directory is also
      needed.




      Does it mean that fsync won't update the directory metadata when I call fsync on a file?



      Another quote for the same problem is(from Robert Love's Book of Linux System Programming):




      Neither function guarantees that any updated directory entries
      containing the file are synchronized to disk. This implies that if a
      file’s link has recently been updated, the file’s data may
      successfully reach the disk but not the associated directory entry,
      rendering the file unreachable.




      Why would a file's data need to reach a directory link ? Correct me if I am wrong but the directories only contain the filename and the inode number for that file. The actual data is in the file. What is the meaning of "the data will reach the file but not the directory link"









      share|improve this question













      share|improve this question




      share|improve this question








      edited Jan 4 at 11:57









      Jeff Schaller

      31.8k848109




      31.8k848109










      asked Jan 4 at 11:26









      ng.newbie

      252211




      252211




















          1 Answer
          1






          active

          oldest

          votes

















          up vote
          1
          down vote



          accepted










          It means:




          if a file’s link has recently been updated



          the file’s data may successfully reach the disk but




          the associated directory entry may not successfully reach the disk




          rendering the file unreachable.




          Specifically, this could be a concern when creating a new file. I would ignore the generalization to "a files link" unless you know hard links are being created.




          Does it mean that fsync won't update the directory metadata when I call fsync on a file?




          Yes. Or rather, you can't rely on it. (It's possible some implementations would always update it before fsync returns.)






          share|improve this answer




















          • what metadata does the directory other than the name of the file and the inode number? Also does this question of not relying on fync only applicable when creating a file?
            – ng.newbie
            Jan 4 at 12:33










          • @ng.newbie it could apply e.g. if you created a second hard-link to a file, and then removed the first hard link. The significant, required metadata is the file name and the inode. I suspect there's nothing mutable in there (apart from the name), because of the possibility of multiple hardlinks. However I believe some filesystems cache more information in there. Specifically, whether the directory entry refers to a directory or a regular file etc. See getdents(). This might allow more efficient implementation of find, for example.
            – sourcejedi
            Jan 4 at 13:14











          Your Answer







          StackExchange.ready(function()
          var channelOptions =
          tags: "".split(" "),
          id: "106"
          ;
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function()
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled)
          StackExchange.using("snippets", function()
          createEditor();
          );

          else
          createEditor();

          );

          function createEditor()
          StackExchange.prepareEditor(
          heartbeatType: 'answer',
          convertImagesToLinks: false,
          noModals: false,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          );



          );








           

          draft saved


          draft discarded


















          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f414749%2fhow-fsync-treats-directory-links%23new-answer', 'question_page');

          );

          Post as a guest






























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes








          up vote
          1
          down vote



          accepted










          It means:




          if a file’s link has recently been updated



          the file’s data may successfully reach the disk but




          the associated directory entry may not successfully reach the disk




          rendering the file unreachable.




          Specifically, this could be a concern when creating a new file. I would ignore the generalization to "a files link" unless you know hard links are being created.




          Does it mean that fsync won't update the directory metadata when I call fsync on a file?




          Yes. Or rather, you can't rely on it. (It's possible some implementations would always update it before fsync returns.)






          share|improve this answer




















          • what metadata does the directory other than the name of the file and the inode number? Also does this question of not relying on fync only applicable when creating a file?
            – ng.newbie
            Jan 4 at 12:33










          • @ng.newbie it could apply e.g. if you created a second hard-link to a file, and then removed the first hard link. The significant, required metadata is the file name and the inode. I suspect there's nothing mutable in there (apart from the name), because of the possibility of multiple hardlinks. However I believe some filesystems cache more information in there. Specifically, whether the directory entry refers to a directory or a regular file etc. See getdents(). This might allow more efficient implementation of find, for example.
            – sourcejedi
            Jan 4 at 13:14















          up vote
          1
          down vote



          accepted










          It means:




          if a file’s link has recently been updated



          the file’s data may successfully reach the disk but




          the associated directory entry may not successfully reach the disk




          rendering the file unreachable.




          Specifically, this could be a concern when creating a new file. I would ignore the generalization to "a files link" unless you know hard links are being created.




          Does it mean that fsync won't update the directory metadata when I call fsync on a file?




          Yes. Or rather, you can't rely on it. (It's possible some implementations would always update it before fsync returns.)






          share|improve this answer




















          • what metadata does the directory other than the name of the file and the inode number? Also does this question of not relying on fync only applicable when creating a file?
            – ng.newbie
            Jan 4 at 12:33










          • @ng.newbie it could apply e.g. if you created a second hard-link to a file, and then removed the first hard link. The significant, required metadata is the file name and the inode. I suspect there's nothing mutable in there (apart from the name), because of the possibility of multiple hardlinks. However I believe some filesystems cache more information in there. Specifically, whether the directory entry refers to a directory or a regular file etc. See getdents(). This might allow more efficient implementation of find, for example.
            – sourcejedi
            Jan 4 at 13:14













          up vote
          1
          down vote



          accepted







          up vote
          1
          down vote



          accepted






          It means:




          if a file’s link has recently been updated



          the file’s data may successfully reach the disk but




          the associated directory entry may not successfully reach the disk




          rendering the file unreachable.




          Specifically, this could be a concern when creating a new file. I would ignore the generalization to "a files link" unless you know hard links are being created.




          Does it mean that fsync won't update the directory metadata when I call fsync on a file?




          Yes. Or rather, you can't rely on it. (It's possible some implementations would always update it before fsync returns.)






          share|improve this answer












          It means:




          if a file’s link has recently been updated



          the file’s data may successfully reach the disk but




          the associated directory entry may not successfully reach the disk




          rendering the file unreachable.




          Specifically, this could be a concern when creating a new file. I would ignore the generalization to "a files link" unless you know hard links are being created.




          Does it mean that fsync won't update the directory metadata when I call fsync on a file?




          Yes. Or rather, you can't rely on it. (It's possible some implementations would always update it before fsync returns.)







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Jan 4 at 11:56









          sourcejedi

          19k32478




          19k32478











          • what metadata does the directory other than the name of the file and the inode number? Also does this question of not relying on fync only applicable when creating a file?
            – ng.newbie
            Jan 4 at 12:33










          • @ng.newbie it could apply e.g. if you created a second hard-link to a file, and then removed the first hard link. The significant, required metadata is the file name and the inode. I suspect there's nothing mutable in there (apart from the name), because of the possibility of multiple hardlinks. However I believe some filesystems cache more information in there. Specifically, whether the directory entry refers to a directory or a regular file etc. See getdents(). This might allow more efficient implementation of find, for example.
            – sourcejedi
            Jan 4 at 13:14

















          • what metadata does the directory other than the name of the file and the inode number? Also does this question of not relying on fync only applicable when creating a file?
            – ng.newbie
            Jan 4 at 12:33










          • @ng.newbie it could apply e.g. if you created a second hard-link to a file, and then removed the first hard link. The significant, required metadata is the file name and the inode. I suspect there's nothing mutable in there (apart from the name), because of the possibility of multiple hardlinks. However I believe some filesystems cache more information in there. Specifically, whether the directory entry refers to a directory or a regular file etc. See getdents(). This might allow more efficient implementation of find, for example.
            – sourcejedi
            Jan 4 at 13:14
















          what metadata does the directory other than the name of the file and the inode number? Also does this question of not relying on fync only applicable when creating a file?
          – ng.newbie
          Jan 4 at 12:33




          what metadata does the directory other than the name of the file and the inode number? Also does this question of not relying on fync only applicable when creating a file?
          – ng.newbie
          Jan 4 at 12:33












          @ng.newbie it could apply e.g. if you created a second hard-link to a file, and then removed the first hard link. The significant, required metadata is the file name and the inode. I suspect there's nothing mutable in there (apart from the name), because of the possibility of multiple hardlinks. However I believe some filesystems cache more information in there. Specifically, whether the directory entry refers to a directory or a regular file etc. See getdents(). This might allow more efficient implementation of find, for example.
          – sourcejedi
          Jan 4 at 13:14





          @ng.newbie it could apply e.g. if you created a second hard-link to a file, and then removed the first hard link. The significant, required metadata is the file name and the inode. I suspect there's nothing mutable in there (apart from the name), because of the possibility of multiple hardlinks. However I believe some filesystems cache more information in there. Specifically, whether the directory entry refers to a directory or a regular file etc. See getdents(). This might allow more efficient implementation of find, for example.
          – sourcejedi
          Jan 4 at 13:14













           

          draft saved


          draft discarded


























           


          draft saved


          draft discarded














          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f414749%2fhow-fsync-treats-directory-links%23new-answer', 'question_page');

          );

          Post as a guest













































































          Popular posts from this blog

          How to check contact read email or not when send email to Individual?

          Bahrain

          Postfix configuration issue with fips on centos 7; mailgun relay