How fsync treats directory links?
Clash 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"
linux directory system-calls
add a comment |Â
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"
linux directory system-calls
add a comment |Â
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"
linux directory system-calls
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"
linux directory system-calls
edited Jan 4 at 11:57
Jeff Schaller
31.8k848109
31.8k848109
asked Jan 4 at 11:26
ng.newbie
252211
252211
add a comment |Â
add a comment |Â
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.)
what metadata does the directory other than the name of the file and the inode number? Also does this question of not relying onfync
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. Seegetdents()
. This might allow more efficient implementation offind
, for example.
â sourcejedi
Jan 4 at 13:14
add a comment |Â
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.)
what metadata does the directory other than the name of the file and the inode number? Also does this question of not relying onfync
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. Seegetdents()
. This might allow more efficient implementation offind
, for example.
â sourcejedi
Jan 4 at 13:14
add a comment |Â
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.)
what metadata does the directory other than the name of the file and the inode number? Also does this question of not relying onfync
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. Seegetdents()
. This might allow more efficient implementation offind
, for example.
â sourcejedi
Jan 4 at 13:14
add a comment |Â
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.)
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.)
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 onfync
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. Seegetdents()
. This might allow more efficient implementation offind
, for example.
â sourcejedi
Jan 4 at 13:14
add a comment |Â
what metadata does the directory other than the name of the file and the inode number? Also does this question of not relying onfync
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. Seegetdents()
. This might allow more efficient implementation offind
, 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
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
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
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password