Llfuse

Latest version: v1.5.1

Safety actively analyzes 681926 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 5 of 7

0.41

=========================

* Fixed a syntax error in contrib/tmpfs.py
* Introduced an `!llfuse.__version__` attribute.
* Added more reasonable default values for `llfuse.EntryAttributes`.
* Added new minimal example, :file:`examples/lltest.py`.
* Added unit tests.
* Added an example for a pass-through file system,
:file:`examples/passthroughfs.py`.

0.40

=========================

* Re-raising an exception from a request handler now works
correctly under Python 3. Problems were caused by a Cython bug,
but llfuse now works around the issue.

* File atime, ctime and mtime can now also be represented as
nanosecond integer values for increased resolution. Thanks to
nagy.attilagmail.com for the initial patch.

* Python-llfuse no longer includes the setuptools/distribute
bootstrap script. This module thus has to be installed manually
if not already present on the system.

* Duck-typing of the Operations instance is now supported.

* Python-llfuse no longer requires a re-compilation of the
Cython code (setup.py build_cython step) when compiling for MacOS
or FreeBSD.

* Extended attributes are now properly supported under FreeBSD.

0.39

=========================

* When running under Python 3.x, several functions now work with
string objects rather than byte objects:

- llfuse.init(): the *mountpoint* argument, and the elements of
the *fuse_opts* argument are expected to be of type str.

- llfuse.listdir(): the *path* argument is expected to be of
type str, and the values returned by the iterator will be of
type str as well.

- llfuse.getxattr(), llfuse.setxattr(): the *path* and *name*
arguments are expected to be of type str.

When necessary, values will be converted to the file system
encoding using the surrogatescape handler as described in PEP 383
(http://www.python.org/dev/peps/pep-0383/)

* Renamed get_off_t_bytes() and get_ino_t_bytes() to
get_off_t_bits() and get_ino_t_bits() and documented them.

0.38

=========================

* Various small bugfixes.

0.37.1

===========================

* Fixed a segfault-causing race condition in Lock.acquire() and
Lock.yield().

0.37

=========================

* Explicitly call fuse_chan_destroy() in llfuse.close(), so
that the mountpoint becomes inaccessible right away, even
while the process is still running.

* Added get_ino_t_bytes() and get_off_t_bytes() that return
the number of bytes used for representing inode numbers
and file offsets.

* The yield_() method of the global lock now takes an additional
*count* argument that can be used to yield the lock more than
once.

* Changed implementation of global lock. The global lock is
no longer a mutex, but a boolean variable protected by a mutex,
and changes are tracked with a condition object. This allows
lock.yield() to work properly: if there are other threads waiting
for the lock, they are guaranteed to run. If there are no other
threads waiting for the lock, execution of the active thread
continues immediately.

The previous implementation using sched_yield() was mostly
broken: threads trying to acquire the global lock were calling
pthread_mutex_lock, so they got removed from the kernels
runqueue. However, calls to sched_yield() would just put the
active thread into the expired runqueue, and calls to
pthread_mutex_unlock apparently do not synchronously move the
threads waiting for the lock back to a runqueue. Therefore, most
of the time the active thread would be the only thread in any
runqueue and thus continue to run.

* The Operations.forget() method now receives a list of
(inode, nlookup) tuples rather than just one such tuple.

* invalidate_entry() and invalidate_inode() no longer work
synchronously. Instead, the message is put in a queue and send by
a background thread.

* The acquire() method of the global lock now has an optional
*timeout* parameter.

* The create() request handler now receives the open flags
as an additional parameter.

Page 5 of 7

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.