You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@buildstream.apache.org by GitBox <gi...@apache.org> on 2022/01/17 16:37:56 UTC
[GitHub] [buildstream] doraskayo opened a new pull request #1568: fuse: Pass through the underlying filesystem's inode numbers
doraskayo opened a new pull request #1568:
URL: https://github.com/apache/buildstream/pull/1568
This PR fixes the following issue detected by `gnulib`:
```
...
checking whether this system has an arbitrary file name length limit... yes
checking for d_ino member in directory struct... no
```
See commit messages for more information.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@buildstream.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [buildstream] juergbi commented on pull request #1568: fuse: Pass through the underlying filesystem's inode numbers
Posted by GitBox <gi...@apache.org>.
juergbi commented on pull request #1568:
URL: https://github.com/apache/buildstream/pull/1568#issuecomment-1015132613
A potential issue I see is that `ensure_copy()` can cause the inode number of an existing file to change when it shouldn't. I don't know whether there are any applications where this would cause an issue. It's likely that filling in the inode number is more important than the potential inconsistency.
OSTree's `rofiles-fuse` also passes through the inode number, an indication that this is not a significant issue.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@buildstream.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [buildstream] doraskayo edited a comment on pull request #1568: fuse: Pass through the underlying filesystem's inode numbers
Posted by GitBox <gi...@apache.org>.
doraskayo edited a comment on pull request #1568:
URL: https://github.com/apache/buildstream/pull/1568#issuecomment-1015839360
@juergbi, you're right. `ensure_copy()` creates a copy of a file when the file is hardlinked, and the new file is assigned a new inode number by the undetlying filesystem. Since this PR passes through the underlying filesystem's inode numbers, this new inode number would be reflected to callers of stat(2).
Without this PR, libfuse's internally-generated inode was consistent for each unique path and as long as the file wasn't unlinked. However, it also meant that different hardlinks of the same file had different inode numbers, which is also somewhat inconsistent, but in a different way.
I honestly don't have a better idea on how to avoid both inconsistencies, or even only the former inconsistency, while also providing a consistent inode number in readdir(2).
Edit: now that I think about it, one can't actually avoid both inconsistencies by definition. It would require returning the same inode number for multiple files which aren't hardlinked in some cases. This means inode numbers wouldn't be unique anymore, which is a much worse option.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@buildstream.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [buildstream] gtristan merged pull request #1568: fuse: Pass through the underlying filesystem's inode numbers
Posted by GitBox <gi...@apache.org>.
gtristan merged pull request #1568:
URL: https://github.com/apache/buildstream/pull/1568
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@buildstream.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [buildstream] doraskayo edited a comment on pull request #1568: fuse: Pass through the underlying filesystem's inode numbers
Posted by GitBox <gi...@apache.org>.
doraskayo edited a comment on pull request #1568:
URL: https://github.com/apache/buildstream/pull/1568#issuecomment-1015839360
@juergbi, you're right. `ensure_copy()` creates a copy of a file when the file is hardlinked, and the new file is assigned a new inode number by the undetlying filesystem. Since this PR passes through the underlying filesystem's inode numbers, this new inode number would be reflected to callers of stat(2).
Without this PR, libfuse's internally-generated inode was consistent for each unique path and as long as the file wasn't unlinked. However, it also meant that different hardlinks of the same file had different inode numbers, which is also somewhat inconsistent, but in a different way.
I honestly don't have a better idea on how to avoid both inconsistencies, or even only the former inconsistency, while providing a consistent inode number in readdir(2). I'm not sure if it's even possible given the limitations of FUSE.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@buildstream.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [buildstream] nanonyme commented on pull request #1568: fuse: Pass through the underlying filesystem's inode numbers
Posted by GitBox <gi...@apache.org>.
nanonyme commented on pull request #1568:
URL: https://github.com/apache/buildstream/pull/1568#issuecomment-1068468129
Related to https://github.com/apache/buildstream/issues/324 "In some situations this can cause issues. E.g., if an unintentionally hardlinked file is modified in place. The SaferHardlinks FUSE layer protects against this during integration. However, the information is also lost when creating images for deployment."
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@buildstream.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [buildstream] doraskayo commented on pull request #1568: fuse: Pass through the underlying filesystem's inode numbers
Posted by GitBox <gi...@apache.org>.
doraskayo commented on pull request #1568:
URL: https://github.com/apache/buildstream/pull/1568#issuecomment-1015839360
@juergbi, you're right. `ensure_copy()` creates a copy of a file when the file is hardlinked, and the new file is assigned a new inode number by the undetlying filesystem. Since this PR passes through the underlying filesystem's inode numbers, this new inode number would be reflected to callers of stat(2).
Without this PR, libfuse's internally-generated inode was consistent for each unique path and as long as the file wasn't removed. However, it also meant that different hardlinks of the same file had different inode numbers, which is also somewhat inconsistent, but in a different way.
I honestly don't have a better idea on how to avoid both inconsistencies while providing a consistent inode number in readdir(2), or even only the former. I'm not sure if it's even possible given the limitations of FUSE.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@buildstream.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [buildstream] juergbi edited a comment on pull request #1568: fuse: Pass through the underlying filesystem's inode numbers
Posted by GitBox <gi...@apache.org>.
juergbi edited a comment on pull request #1568:
URL: https://github.com/apache/buildstream/pull/1568#issuecomment-1015132613
A potential issue I see is that `ensure_copy()` can cause the inode number of an existing file to change when it shouldn't. I don't know whether there are any applications where this would cause an issue. It's likely that filling in the inode number is more important than the potential inconsistency.
OSTree's `rofiles-fuse` also passes through the inode number, an indication that this is not a significant issue.
https://github.com/ostreedev/ostree/blob/main/src/rofiles-fuse/main.c#L137
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@buildstream.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org