3 ms·

> The open-source client does not emulate operations like directory renames that would require many S3 API calls or POSIX file system features that are not supp

> The open-source client does not emulate operations like directory renames that would require many S3 API calls or POSIX file system features that are not supported in S3 APIs. At this point I'd probably be fine with using a different API than the filesystem, perhaps one inside of whatever backend language I was using Feels more fused than mounted

yetanotherloss 4y ago
Indeed, if you're getting that far away from historical file systems primitives then may as well use an API model that makes senses for the storage backend. Or just contribute direct to rclone and fuse.
RantyDave 4y ago
You can open an s3 object as a 'file object' in python and it is at least seekable. Other than that I think you're best to treat s3 as a huge kv store and not a filesystem at all.
- dontlaugh 4y ago
  Seek only works because the whole object gets downloaded into memory first.
  - rbanffy 4y ago
    Either that, or the Unix principle of many small files being better than a single big one (without the need to worry about inode exhaustion in S3).
    - dontlaugh 4y ago
      S3 works best with a bunch of medium and similar sized files. It’s really not like a file system.
      - RantyDave 4y ago
        Right. Big and slow kv.
      - rbanffy 4y ago
        Reminds me of tape-based storage like the Sinclair QL or Exatron's "stringy floppy". Or Mitsumi's QuickDisk, a format I saw on the Sharp MZ series which is not a disk, but a spiral track that looks a lot like a loop of tape running past RW heads.