<commit_before># FAQ

### How does it compare to hubicfuse, cloudfuse, swiftFS ... ?

SVFS supports authentication versions 1/2/3, is stable and fully connected.
This means SVFS won't play with unsafe pointers all the time,
avoiding segfaults. Also, SVFS will make read/write operations atomic :
it won't return to the caller until data has been read/written from/to the
network. In other words no local buffering is taking place so i.e. if you
want to rsync to/from an SVFS mountpoint you will get the real progress
of this operation and not the progress of local buffering. An other consequence
is that you'll never require space on your local disk to read/write data from
a file. Standard buffering is done in memory and your data is always a stream
on the network. This is not the role of a network filesystem to chose how your
data should be accessed : it should be consistent across operations. If you are
looking for local speed rates, then this means you are looking for a local
filesystem and SVFS is no more than a easier way to achieve synchronization
between both since it brings support for usual tools when used with appropriate options
(for instance `rsync -av -W --inplace --size-only --progress`). In this case you should rely
on an appropriate, journalized, battle-hardened local filesystem. This is also
where you should manage ownership, permissions and other ACL/extended attributes
information, relatively to your local users and groups.

### Why can't I set uid/guid and permissions ?

Openstack Swift object storage does not handle file ownership or permissions
in a way which is compatible with POSIX filesystems. Indeed, Swift supports
ACLs however it can not be converted reliably as file permissions or ownership.
A basic implementation could use Swift's metadata to make this possible but the
performance impact would be huge since a request would be necessary for every
single file within a container and it makes little sense as uid/gid mapping 
can differ between two mountpoints.

### Why are creation/access times erroneous ?

Openstack Swift only stores the modification time of an object so this<commit_msg>Rsync usage clarification<commit_after># FAQ

### How does it compare to hubicfuse, cloudfuse, swiftFS ... ?

SVFS supports authentication versions 1/2/3, is stable and fully connected.
This means SVFS won't play with unsafe pointers all the time,
avoiding segfaults. Also, SVFS will make read/write operations atomic :
it won't return to the caller until data has been read/written from/to the
network. In other words no local buffering is taking place so i.e. if you
want to rsync to/from an SVFS mountpoint you will get the real progress
of this operation and not the progress of local buffering. An other consequence
is that you'll never require space on your local disk to read/write data from
a file. Standard buffering is done in memory and your data is always a stream
on the network. This is not the role of a network filesystem to chose how your
data should be accessed : it should be consistent across operations. If you are
looking for local speed rates, then this means you are looking for a local
filesystem and SVFS is no more than a easier way to achieve synchronization
between both since it brings support for usual tools when used with appropriate options
(for instance `rsync -av -W --inplace --size-only --progress` for the first run
then `rsync -av -W --inplace -u --progress` afterwards). In this case you should rely
on an appropriate, journalized, battle-hardened local filesystem. This is also
where you should manage ownership, permissions and other ACL/extended attributes
information, relatively to your local users and groups.

### Why can't I set uid/guid and permissions ?

Openstack Swift object storage does not handle file ownership or permissions
in a way which is compatible with POSIX filesystems. Indeed, Swift supports
ACLs however it can not be converted reliably as file permissions or ownership.
A basic implementation could use Swift's metadata to make this possible but the
performance impact would be huge since a request would be necessary for every
single file within a container and it makes little sense as uid/gid mapping
can differ between two mountpoints.

### Why are creation/access times erroneous ?

Openstack Swift only stores the modification time of an object so this
{'fraction_non_alphanumeric': 0.03729977116704806, 'fraction_numerical': 0.0013729977116704805, 'mean_word_length': 4.429813664596273, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '6831424', 'n_tokens_mistral': 1054, 'n_tokens_neox': 1000, 'n_words': 689}