<feed xmlns='http://www.w3.org/2005/Atom'>
<title>gocryptfs/internal/fusefrontend_reverse/virtualnode.go, branch xattr_user_buffer</title>
<subtitle>Mirror of gocryptfs source code on Github</subtitle>
<id>http://nuetzlich.net/cgit/gocryptfs/atom?h=xattr_user_buffer</id>
<link rel='self' href='http://nuetzlich.net/cgit/gocryptfs/atom?h=xattr_user_buffer'/>
<link rel='alternate' type='text/html' href='http://nuetzlich.net/cgit/gocryptfs/'/>
<updated>2025-01-18T13:13:52+00:00</updated>
<entry>
<title>reverse: advance mtime &amp; ctime for virtual files by 10 seconds</title>
<updated>2025-01-18T13:13:52+00:00</updated>
<author>
<name>Jakob Unterwurzacher</name>
</author>
<published>2025-01-18T13:11:51+00:00</published>
<link rel='alternate' type='text/html' href='http://nuetzlich.net/cgit/gocryptfs/commit/?id=9eb47cf546d7e2499eab210d70050ef78087475a'/>
<id>urn:sha1:9eb47cf546d7e2499eab210d70050ef78087475a</id>
<content type='text'>
With inode number reuse and hard links, we could have returned
wrong data for gocryptfs.diriv and gocryptfs.xyz.longname files, respectively
(https://github.com/rfjakob/gocryptfs/issues/802).

Now that this is fixed, ensure that rsync and similar tools pick up the new
correct files by advancing mtime and ctime by 10 seconds, which should be more
than any filesytems' timestamp granularity (FAT32 has 2 seconds).
</content>
</entry>
<entry>
<title>reverse: fix force_owner</title>
<updated>2024-08-23T20:32:46+00:00</updated>
<author>
<name>Jakob Unterwurzacher</name>
</author>
<published>2024-08-23T20:32:46+00:00</published>
<link rel='alternate' type='text/html' href='http://nuetzlich.net/cgit/gocryptfs/commit/?id=f665be1178c72a4768e82bccdfa073a0cf309215'/>
<id>urn:sha1:f665be1178c72a4768e82bccdfa073a0cf309215</id>
<content type='text'>
Fixes https://github.com/rfjakob/gocryptfs/issues/809
</content>
</entry>
<entry>
<title>reverse: use incrementing inode number for gocryptfs.longname.*.name files</title>
<updated>2024-05-05T20:46:17+00:00</updated>
<author>
<name>Jakob Unterwurzacher</name>
</author>
<published>2024-05-05T20:46:17+00:00</published>
<link rel='alternate' type='text/html' href='http://nuetzlich.net/cgit/gocryptfs/commit/?id=a38507978442f28ace42ec0003c4a2bf61cb4a91'/>
<id>urn:sha1:a38507978442f28ace42ec0003c4a2bf61cb4a91</id>
<content type='text'>
ed0a12b7337c2d88c027329f64e73070da17d5b3 already fixed the kernel side,
now we also want the .name files to NOT appear hardlinked when just
looking at the inode number.

Relates-to: https://github.com/rfjakob/gocryptfs/issues/802
</content>
</entry>
<entry>
<title>go mod: declare module version v2</title>
<updated>2021-08-23T13:05:15+00:00</updated>
<author>
<name>Jakob Unterwurzacher</name>
</author>
<published>2021-08-23T13:05:15+00:00</published>
<link rel='alternate' type='text/html' href='http://nuetzlich.net/cgit/gocryptfs/commit/?id=69d88505fd7f4cb0d9e4f1918de296342fe05858'/>
<id>urn:sha1:69d88505fd7f4cb0d9e4f1918de296342fe05858</id>
<content type='text'>
Our git version is v2+ for some time now, but go.mod
still declared v1. Hopefully making both match makes
https://pkg.go.dev/github.com/rfjakob/gocryptfs/v2 work.

All the import paths have been fixed like this:

  find . -name \*.go | xargs sed -i s%github.com/rfjakob/gocryptfs/%github.com/rfjakob/gocryptfs/v2/%
</content>
</entry>
<entry>
<title>-deterministic-names: implement for reverse mode, too</title>
<updated>2021-08-20T15:06:18+00:00</updated>
<author>
<name>Jakob Unterwurzacher</name>
</author>
<published>2021-08-20T15:06:18+00:00</published>
<link rel='alternate' type='text/html' href='http://nuetzlich.net/cgit/gocryptfs/commit/?id=fbccb160438aba6f1e16b26a982122c726afee1a'/>
<id>urn:sha1:fbccb160438aba6f1e16b26a982122c726afee1a</id>
<content type='text'>
</content>
</entry>
<entry>
<title>v2api/reverse: implement Read</title>
<updated>2020-08-09T20:11:46+00:00</updated>
<author>
<name>Jakob Unterwurzacher</name>
</author>
<published>2020-08-09T20:11:46+00:00</published>
<link rel='alternate' type='text/html' href='http://nuetzlich.net/cgit/gocryptfs/commit/?id=6d4f1a6888cafd218cb97bd11de6a7553d9bc8f1'/>
<id>urn:sha1:6d4f1a6888cafd218cb97bd11de6a7553d9bc8f1</id>
<content type='text'>
</content>
</entry>
</feed>
