<feed xmlns='http://www.w3.org/2005/Atom'>
<title>gocryptfs/internal/fusefrontend, branch v0.10</title>
<subtitle>Mirror of gocryptfs source code on Github</subtitle>
<id>http://nuetzlich.net/cgit/gocryptfs/atom?h=v0.10</id>
<link rel='self' href='http://nuetzlich.net/cgit/gocryptfs/atom?h=v0.10'/>
<link rel='alternate' type='text/html' href='http://nuetzlich.net/cgit/gocryptfs/'/>
<updated>2016-05-30T07:36:06+00:00</updated>
<entry>
<title>fusefrontend: replace unreliable "fd &lt; 0" check</title>
<updated>2016-05-30T07:36:06+00:00</updated>
<author>
<name>Jakob Unterwurzacher</name>
</author>
<published>2016-05-30T07:29:30+00:00</published>
<link rel='alternate' type='text/html' href='http://nuetzlich.net/cgit/gocryptfs/commit/?id=5dd9576a11bb166e5b3cad70047a46038daf32d6'/>
<id>urn:sha1:5dd9576a11bb166e5b3cad70047a46038daf32d6</id>
<content type='text'>
... with the "released" boolean.

For some reason, the "f.fd.Fd() &lt; 0" check did not work reliably,
leading to nil pointer panics on the following wlock.lock().

The problem was discovered during fsstress testing and is unlikely
to happen in normal operations.

With this change, we passed 1700+ fsstress iterations.
</content>
</entry>
<entry>
<title>fusefrontend: use sync.Once for one-time warnings</title>
<updated>2016-05-29T20:50:03+00:00</updated>
<author>
<name>Jakob Unterwurzacher</name>
</author>
<published>2016-05-29T20:50:03+00:00</published>
<link rel='alternate' type='text/html' href='http://nuetzlich.net/cgit/gocryptfs/commit/?id=1648c54adb9b7d9d8984857a35c6092bbae6bdec'/>
<id>urn:sha1:1648c54adb9b7d9d8984857a35c6092bbae6bdec</id>
<content type='text'>
Using a simple boolean was racy (which was harmless
in this case) and non-idomatic.
</content>
</entry>
<entry>
<title>fusefronted: check Fstat return value on file create</title>
<updated>2016-05-29T20:43:48+00:00</updated>
<author>
<name>Jakob Unterwurzacher</name>
</author>
<published>2016-05-29T20:41:46+00:00</published>
<link rel='alternate' type='text/html' href='http://nuetzlich.net/cgit/gocryptfs/commit/?id=fd53dfd2ad88d9d277e5ab93fba1b81a5f2255d4'/>
<id>urn:sha1:fd53dfd2ad88d9d277e5ab93fba1b81a5f2255d4</id>
<content type='text'>
The Fstat call should never fail, but still, if it does return an error
it should be handled properly.
</content>
</entry>
<entry>
<title>fusefrontend: simplify wlockMap</title>
<updated>2016-05-29T20:40:05+00:00</updated>
<author>
<name>Jakob Unterwurzacher</name>
</author>
<published>2016-05-29T20:40:05+00:00</published>
<link rel='alternate' type='text/html' href='http://nuetzlich.net/cgit/gocryptfs/commit/?id=77813bdc13118fd08bbff7a68c9d5268080a2a15'/>
<id>urn:sha1:77813bdc13118fd08bbff7a68c9d5268080a2a15</id>
<content type='text'>
mapMutex can be anonymous and using an RWMutex is overkill
because the lock protects very short sections.
</content>
</entry>
<entry>
<title>fusefrontend: remove unused "forgotten" variable</title>
<updated>2016-05-29T11:46:47+00:00</updated>
<author>
<name>Jakob Unterwurzacher</name>
</author>
<published>2016-05-29T11:46:47+00:00</published>
<link rel='alternate' type='text/html' href='http://nuetzlich.net/cgit/gocryptfs/commit/?id=4c0cb37c50c66b03be43063d77a52b74f24ec9f7'/>
<id>urn:sha1:4c0cb37c50c66b03be43063d77a52b74f24ec9f7</id>
<content type='text'>
The functionality has long been replaced by the fd &lt; 0
check.
</content>
</entry>
<entry>
<title>Encrypt path in statfs() calls</title>
<updated>2016-05-12T21:24:39+00:00</updated>
<author>
<name>David Gnedt</name>
</author>
<published>2016-05-12T17:51:13+00:00</published>
<link rel='alternate' type='text/html' href='http://nuetzlich.net/cgit/gocryptfs/commit/?id=a93bcabe9c1dea14bf29b94cbddf62c1bec4d315'/>
<id>urn:sha1:a93bcabe9c1dea14bf29b94cbddf62c1bec4d315</id>
<content type='text'>
Paths in statfs() calls were not encrypted resulting in
an Function not implemented error, when the unencrypted
path didn't exist in the underlying (encrypted)
filesystem.

$ df plain/existingdir
df: ‘plain/existingdir’: Function not implemented
</content>
</entry>
<entry>
<title>fusefrontend: fix panic due to concurrently unregistered wlock</title>
<updated>2016-05-08T21:21:20+00:00</updated>
<author>
<name>Jakob Unterwurzacher</name>
</author>
<published>2016-05-08T21:16:40+00:00</published>
<link rel='alternate' type='text/html' href='http://nuetzlich.net/cgit/gocryptfs/commit/?id=ba7c798418269e6d496af206bdebd2204a07155f'/>
<id>urn:sha1:ba7c798418269e6d496af206bdebd2204a07155f</id>
<content type='text'>
Commit 730291feab properly freed wlock when the file descriptor is
closed. However, concurrently running Write and Truncates may
still want to lock it. Check if the fd has been closed first.
</content>
</entry>
<entry>
<title>fusefrontend: fix wlock memory leak</title>
<updated>2016-05-05T11:38:39+00:00</updated>
<author>
<name>Jakob Unterwurzacher</name>
</author>
<published>2016-05-05T11:38:39+00:00</published>
<link rel='alternate' type='text/html' href='http://nuetzlich.net/cgit/gocryptfs/commit/?id=730291feabdcdbd6345aa12ddba87a3ffea4ecb1'/>
<id>urn:sha1:730291feabdcdbd6345aa12ddba87a3ffea4ecb1</id>
<content type='text'>
The write lock was not freed on release, causing a slow memory leak.

This was noticed by running extractloop.bash for 10 hours.
</content>
</entry>
<entry>
<title>prelloc: warn and continue if fallocate(2) is not supported</title>
<updated>2016-04-20T20:47:31+00:00</updated>
<author>
<name>Jakob Unterwurzacher</name>
</author>
<published>2016-04-20T20:47:31+00:00</published>
<link rel='alternate' type='text/html' href='http://nuetzlich.net/cgit/gocryptfs/commit/?id=4d79fba2853b7d0b5f4cafc4aab55b1c448282e3'/>
<id>urn:sha1:4d79fba2853b7d0b5f4cafc4aab55b1c448282e3</id>
<content type='text'>
This makes gocryptfs work at all on ZFS.
See https://github.com/rfjakob/gocryptfs/issues/22 .
</content>
</entry>
<entry>
<title>Fix "go tool vet -shadow=true" warnings</title>
<updated>2016-04-10T19:31:15+00:00</updated>
<author>
<name>Jakob Unterwurzacher</name>
</author>
<published>2016-04-10T19:29:42+00:00</published>
<link rel='alternate' type='text/html' href='http://nuetzlich.net/cgit/gocryptfs/commit/?id=bd5405189eb27d463e25c43691b19dbdf174d3a8'/>
<id>urn:sha1:bd5405189eb27d463e25c43691b19dbdf174d3a8</id>
<content type='text'>
Among those one real bug.
</content>
</entry>
</feed>
