pytagsfs team mailing list archive
Mailing list archive
[ANNOUNCE] pytagsfs version 0.9.2
I'm pleased to announce the release of pytagsfs version 0.9.2. This release
addresses several critical bugs. All users are encouraged to upgrade.
Some of the bugs fixed by this release could have caused data inconsistencies in
certain situations. Data corruption is only possible when the filesystem is
mounted writable and virtual files are actually written to.
With all of the bugs fixed in this release that could have caused data
corruption, filesystem operations would have returned error codes. It is not
possible (as far as I am aware) to have seen silent data corruption.
As always, users are encouraged to keep recent backups of data. pytagsfs is
free software and is provided "as is" without warranty of any kind. See the
file COPYING distributed with the pytagsfs source code for more information.
It is worth noting that I have not received any user reports of data corruption
caused by pytagsfs. Also, all of the bugs fixed in this release that could have
caused data corruption would also have caused tests to fail. Running the test
suite is an easy way to confirm that data corruption is unlikely (but, of
course, it is never impossible). To run the test suite, download the pytagsfs
source and run the command ``./setup.py test``. Running the test suite should
take somewhere between 10 and 30 minutes (it takes about 15 minutes on my
Major changes introduced by the 0.9.2 release:
* Two bugs related to changes and bugs in the python-fuse bindings were
fixed and work-arounds were introduced. Both of these issues could have led
to data corruption in some circumstances.
* A bug where both filesystem errors and data inconsistencies could be seen
when a virtual file is opened for writing more than once at the same time.
Since two processes writing to the same file concurrently would likely
result in inconsistent data, anyway, this issue is not likely to have caused
problems under practical circumstances.
* Fixes were introduced to correct pervasive locking issues that in many
situations would have caused the filesystem to become unresponsive due to
deadlocked threads. This would only occur if the filesystem is being
accessed concurrently by multiple processes. Data corruption is possible,
but due to the severity of the issues, the filesystem would probably have
locked up before a file could be opened for writing.
* Performance with debug logging enabled was improved.
* Introduced FUSE option max_readahead=0. This has no impact on OS X because
MacFUSE-specific option noreadahead was already being used.
Since the underlying source files can change at any time, no in-kernel
caching can be permitted. Otherwise, reads may return old data. This makes
read performance worse by a factor of about two on my machine (but
correctness is more important than performance by a factor of greater than
The previous behavior could lead to data inconsistencies if a virtual file
and its corresponding real file were being written to simultaneously.
However, data inconsistencies would occur under those circumstances even in
the absence of this issue.
* Symlinks in the source tree are now completely ignored. Previously, they
were represented as virtual symlinks but readlink calls would fail. In the
future, we'd like to follow symlinks and handle them correctly.
* Fixed a bug that arises when a file is opened for writing twice after being
either opened for reading and subsequently truncated or truncated and
subsequently opened for reading. The second attempt to open the file for
writing would fail. This bug could not cause data corruption.
*** Mac OS X testers needed ***
Running pytagsfs on an OS X machine? Please take the time to run the test suite
and report the results (success or failure) to the pytagsfs mailing list.
*** Packagers take note: ***
Please integrate test suite execution into your build scripts or at least run
the test suite when packaging a new version of pytagsfs or when a new version of
the fuse-python bindings is packaged. There are circumstances outside of my
control that can cause critical bugs that could lead to data corruption.
Specifically, pytagsfs is vulnerable to changes in the python-fuse bindings.
In that past, there were a few tests that would intermittently fail with
relatively high frequency. These tests have now been corrected to pass under
virtually all circumstances.
However, there remain some tests that do fail incorrectly on occasion. For
instance, if disk free space is rapidly fluctuating, tests that compare stat
results may fail. These tests have been designed to compare results loosely to
accommodate typical variations. However, if the system is heavily loaded or the
disks are being used extensively, they may fail on occasion. I will be making an
effort to reduce the possibility of false positives, but I believe the situation
is reasonably under control at present.
As such, there is little reason not to run the test suite when building packages
for distribution. Please consider doing so.
The full set of changes for this release is available:
To download this release:
pytagsfs is a FUSE filesystem that arranges media files in a virtual directory
structure based on the file tags. For instance, a set of audio files could be
mapped to a new directory structure organizing them hierarchically by album,
genre, release date, etc. File tags can be changed by moving and renaming
virtual files and directories. The virtual files can also be modified directly,
and, of course, can be opened and played just like regular files.
For a more thorough introduction, see:
Please visit http://www.pytagsfs.org to obtain more information.
Feel free to contact me with any questions. Feedback is appreciated.
Description: Digital signature