-
Notifications
You must be signed in to change notification settings - Fork 468
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
vfs: MemFS Link erroneously shares refcount #2064
Comments
This was referenced Oct 27, 2022
jbowens
added a commit
to jbowens/pebble
that referenced
this issue
Oct 27, 2022
Default to Unix semantics in MemFS. The Windows semantics are left as configurable for unit tests that seek to ensure we don't remove open files, when possible. There are existing cases where we cannot satisfy Windows semantics, and Go does not support opening files with the appropriate `FILE_SHARE_DELETE` permission bit (see golang/go#34681, golang/go#32088). The MemFS's implementation of Windows semantics is useful for ensuring we don't regress in the cases where we can satisfy Windows semantics. Close cockroachdb#2064. Informs cockroachdb#1236.
jbowens
added a commit
that referenced
this issue
Oct 27, 2022
Default to Unix semantics in MemFS. The Windows semantics are left as configurable for unit tests that seek to ensure we don't remove open files, when possible. There are existing cases where we cannot satisfy Windows semantics, and Go does not support opening files with the appropriate `FILE_SHARE_DELETE` permission bit (see golang/go#34681, golang/go#32088). The MemFS's implementation of Windows semantics is useful for ensuring we don't regress in the cases where we can satisfy Windows semantics. Close #2064. Informs #1236.
jbowens
added a commit
to jbowens/pebble
that referenced
this issue
Oct 16, 2023
Default to Unix semantics in MemFS. The Windows semantics are left as configurable for unit tests that seek to ensure we don't remove open files, when possible. There are existing cases where we cannot satisfy Windows semantics, and Go does not support opening files with the appropriate `FILE_SHARE_DELETE` permission bit (see golang/go#34681, golang/go#32088). The MemFS's implementation of Windows semantics is useful for ensuring we don't regress in the cases where we can satisfy Windows semantics. Close cockroachdb#2064. Informs cockroachdb#1236.
jbowens
added a commit
that referenced
this issue
Oct 17, 2023
Default to Unix semantics in MemFS. The Windows semantics are left as configurable for unit tests that seek to ensure we don't remove open files, when possible. There are existing cases where we cannot satisfy Windows semantics, and Go does not support opening files with the appropriate `FILE_SHARE_DELETE` permission bit (see golang/go#34681, golang/go#32088). The MemFS's implementation of Windows semantics is useful for ensuring we don't regress in the cases where we can satisfy Windows semantics. Close #2064. Informs #1236.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
vfs.Link
1 reuses the same*memNode
for the old and new location. In particular, this means that itsrefs
field2 is now shared. This means that a hardlinked file cannot be deleted if the original is currently open (or vice versa):We should not share the atomic. The hard-link should get its own atomic counter.
When this is fixed, this work-around can probably be removed:
pebble/ingest.go
Lines 282 to 298 in 5a2941f
Found while investigating a CRDB log truncation test3.
See also #1236
Footnotes
https://github.com/cockroachdb/pebble/blob/b82ab1300c3a5320a68b1607df271d310b737086/vfs/mem_fs.go#L208-L248 ↩
https://github.com/cockroachdb/pebble/blob/b82ab1300c3a5320a68b1607df271d310b737086/vfs/mem_fs.go#L498 ↩
https://github.com/cockroachdb/cockroach/pull/89632#issuecomment-1293415352 ↩
The text was updated successfully, but these errors were encountered: