When uploading a file to a shared folder, the file doesn't end up in the desired destination. about flysystem-google-drive-ext HOT 10 CLOSED

Hi, if you still can't upload in shared folder here I have tested it.

Add this option to boot function in app/Providers/GoogleServiceProvider.php

$options['useDisplayPaths'] = false;

could look like this

public function boot(): void
    {
        try {
            Storage::extend('google', function($app, $config) {
                $options = [];
                $options['useDisplayPaths'] = false;

                if (!empty($config['teamDriveId'] ?? null)) {
                    $options['teamDriveId'] = $config['teamDriveId'];
                }

                $client = new \Google\Client();
                $client->setClientId($config['clientId']);
                $client->setClientSecret($config['clientSecret']);
                $client->refreshToken($config['refreshToken']);
                
                $service = new \Google\Service\Drive($client);
                $adapter = new \Masbug\Flysystem\GoogleDriveAdapter($service, $config['folder'] ?? '/', $options);
                $driver = new \League\Flysystem\Filesystem($adapter);

                return new \Illuminate\Filesystem\FilesystemAdapter($driver, $adapter);
            });
        } catch (\Exception $e) {
            Log::error($e);
        }
    }

Then just use shared folder id to your .env

GOOGLE_DRIVE_CLIENT_ID=xxx.apps.googleusercontent.com
GOOGLE_DRIVE_CLIENT_SECRET=xxx
GOOGLE_DRIVE_REFRESH_TOKEN=xxx
GOOGLE_DRIVE_FOLDER=1GDxXxjT_ohPQtkm5lhK9CAbpxQae5lfO

That option will override to use IDs instead of display path.

from flysystem-google-drive-ext.

Okay, I'll be working on a reproducible test case first thing Tuesday morning (when my office is open again).

from flysystem-google-drive-ext.

Seems like a question for discussions section, no on issues section

Google change how shared drives works

• https://developers.google.com/drive/api/v3/reference/files/list
• #62
• #57 (comment)
• erikn69/laravel-google-drive-ext-demo#1 (comment)

If you think that there is a bug please share an example to replicate it

from flysystem-google-drive-ext.

This is a bug to the best of my knowledge, this is not a shared drive I stated several times it's a shared folder. You made a comment on Working with Shared Drives, that using a shared folder should work the same as a regular folder.

I have this Folder in my drive (my personal gmail), and I'm sharing it with my work email with edit permissions (a gsuite account).

I attempted to use it like a regular folder, and it's creating a folder by that name on the account used to perform the action. (In this case I'm using my gsuite account to perform the uploads)

When attempting to use the following code to upload the file to that shared folder,

Artisan::command('test', function () {
    dd(\Illuminate\Support\Facades\Storage::disk('reporting-folder')->put('hello', 'hello'));
});

this package instead creates a folder under my work email account instead of uploading to the shared folder.

When attempting to use the ID of the folder like our production account does with [email protected]

This package creates a folder by the name of the folder ID instead of uploading to the expected shared folder.

Keeping the configuration of using the folder ID to upload the file, I reverted our app back to the 1.x version of this package. I ran the same test command to upload a file to the folder and this time it uploaded to the shared folder as expected instead of creating a folder.

Based on everything I've seen talked about in the issues, in the readme, and in the discussion says that the behavior of 2.x in this particular case should be the same as 1.x, unless I'm misunderstanding here.

from flysystem-google-drive-ext.

Seems like you didn't read the example
https://github.com/masbug/flysystem-google-drive-ext#add-disks-on-configfilesystemsphp
There is no root on the config

Follow documentation exactly or please share an example to replicate it

From 1.x to 2.x there are many breaking changes, all because flysystems changes from 1.x to 3.x

I have no problems with shared folders

Also you can test this demo: https://github.com/erikn69/laravel-google-drive-ext-demo

Did you try not putting anything in the root propertie?

from flysystem-google-drive-ext.

I did read the example, but the specific change to not using root is wholly dependant on how you implement the driver. In this case the change of the array key is arbitrary and does not impact the expected functionality.

Here's how our app builds the google client.

Here's how we're binding it:

And here's how we're creating the driver

I have changed the root property to folder, and the resulting behavior is the exact same as I described in my first and second posts.

from flysystem-google-drive-ext.

Sorry i can't replicate your problem, make a failing test or a failing demo on fresh installation
Run the tests on your shared folder GoogleDriveAdapterTests.php

In addition, your implementation is not the usual one, I cannot deduce that it could be failing

from flysystem-google-drive-ext.

I come with a little bit of information. The behavior my team is specifically experiencing appears to be the same as if you were to try to upload to a folder that doesn't exist. Previously such an act would cause exceptions to be thrown, however, it's catching the exception and creating the folder it thinks should be there

After a lot of debugging with Xdebug, I've been able to pinpoint the behavior we're experiencing, and for us, it's unexpected behavior for us however it looks like expected behavior for this library.

Here are the sequence of events our system ends up going through

• When a new instance of the driver is created, the system attempts to find the single virutal path of the root folder, which is the second argument of the class constructor.
• Within the constructor, if you're not using a shared team drive, is a call to toVirtualPath, and it attempts to look up the folder in the class's cache by the name passed. Since we're working with a shared folder, we're using folder Ids.
• The folder, not having been cached, is throwing the exception on line 2006 essentially saying the folder/path doesn't exist.
• Since the 4th argument in the constructor mentioned in 1. is true, when the driver catchs the exception it attempts to create the root directory
• Since my team gives it an ID instead of the folder, it creates the ID as the root folder, instead of identifying the shared folder.
• Then when attempting to upload, it already has that cached folder, so it uploads the file there instead of to the shared folder.

After looking through the library's code, it seems like creating a missing folder is intended functionality here. That being the case I've advised my team that we should move to a shared drive instead of relying on shared folders.

I've tested our use with a shared drive, and new folder names (instead of IDs) and everything appeared to work as expected, our files ended up in the shared drive instead of getting lost in our automation's account.

from flysystem-google-drive-ext.

I am experiencing the same, and I have no option to use a shared drive. Is there any direction how to solve this using shared folders instead?

from flysystem-google-drive-ext.

@parijke hi, feel free to make a pull request if you think that it's a bug

from flysystem-google-drive-ext.