m2mtech / flysystem-stream-wrapper Goto Github PK

To prevent the visibility problem there is a try catch around this operation

        try {
            $visibility = $current->filesystem->visibility($current->file);
        } catch (UnableToRetrieveMetadata $e) {
            if (!$current->ignoreVisibilityErrors()) {
                throw $e;
            }

            $visibility = Visibility::PUBLIC;
        }

in StreamStatCommand.php

However, if the adapter just returns the default flysytems' FileAttributes object, which sets visiblity to null (as f.e. spaties dropboxadapter does, a bug in Flysystem will give a TypeError since the visibility function should not return null but a string (reported there). The TypeError is not caught by the above catch. It is probably a good idea to accept a wider range of throwables since any adapter may find their own way of letting know that visibility isn't a thing.

Currently on a migration and using this library. I need to fork it though and add the following line for it to work:

StreamWrapper::109

                if (is_resource($this->current->handle)) {
                    fseek($this->current->handle, $currentPosition);
                }

I don't know why this is needed there, but everything works fine afterwards. Maybe it is because the Stream is being rewinded after Flysystems writeStream.

They also check weather or not the resource is seekable. That might be the right check.

Add replace key to composer.json so this package can be installed instead of

Explanation: https://stackoverflow.com/a/18905069

We try to send E-Mails with Symfony's Mailer over async Messenger component.

The App creates attachments and triggers the SendMailMessage. We use the flysystem-stream-wrapper to store those attachments on a secure S3 storage.

It fails with Path [REDACTED] is not readable. in DataPart.php (Symfony Mailer Component)

Locally, it is somehow not a problem. So I thought it could have been something about the locking component, but changing the lock to in-memory and TTL to 1 second did not resolve the issue.

So, I did a lot of debugging and printing and here are the results:

{
  attachment: {0}
  fileInfo: {}
  fileName: "[REDACTED]"
  isFile: true
  isReadable: false
  path: "gcloud://"
  pathInfo: {}
  pathname: "gcloud://[REDACTED]"
  realPath: false
  stat: {
    0: 0
    1: 0
    10: 1656327883
    11: -1
    12: -1
    2: 33152
    3: 0
    4: 0
    5: 65534
    6: 0
    7: 36798
    8: 1656327883
    9: 1656327883
    atime: 1656327883
    blksize: -1
    blocks: -1
    ctime: 1656327883
    dev: 0
    gid: 65534
    ino: 0
    mode: 33152
    mtime: 1656327883
    nlink: 0
    rdev: 0
    size: 36798
    uid: 0
  }
}

It seems to fail at is_readable, which returns false. So I tried to check the mode using stat, as I figured out with a bit of php source code reading that it seems to use that.

Ignoring the is_readable, I tried to open the file to make sure the FlySystem is setup correctly:

And it actually works:

So the bug would seem to be, that the StreamStatCommand is not setting the right mode?

When using the wrapper with https://github.com/thephpleague/flysystem-azure-blob-storage, the underlying adapter will take over handling the passed stream handle. It means that $this->current->handle could be closed when trying to fseek() and close it.

I'm running into issues with the following code (minimal reproduction - my actual use case involves a third party lib)

FlysystemStreamWrapper::register(
  "fly",
  new Filesystem(new LocalFilesystemAdapter("./")),
);
mkdir("fly://my-dir", 0666, true);
is_writable("fly://my-dir");

Expected
is_writable should return true

Actual
is_writable returns false

Research
When a new directory is created inside the FlysystemStreamWrapper, it seems as if permissions are set to 755, meaning only the owner may write to the directory. Calling fileowner("fly://my-dir") returns 0 which is equivalent to the root user on my system - i.e. not my php user. This appears to cause php to believe it does not have write access to "my-dir".

Forcing a write despite is_writable proves that the directory is, in fact, writable.

Problems

1. FlysystemStreamWrapper does not create directories with the requested access rights
2. Created directories erroneously report owner 0

Can you please allow symfony 7 components and make a release?