Enhancements

[army1349]

Thanks for this plugin!

Would you consider:

1. Command execution for created folders,
2. Filtering by operation,
3. Better path variable support for Local External Storages?

[blizzz]

Command execution for created folders,

should work already

Filtering by operation,

what do you mean?

Better path variable support for Local External Storages?

would you elaborate her as well?

[army1349]

Command execution for created folders,

should work already

I can't see such trigger and it doesn't work for me with "File created"

Filtering by operation,

what do you mean?

There was probably no "When" for selecting triggers whet I raised this issue?

Better path variable support for Local External Storages?

would you elaborate her as well?

User has external storage of type local: /home/userName mounted as /,
but for %n I get path like /userName/files/folderName/fileName.txt, which is not very handy.
Edit: %f does not work either and I don't like use of toTmpFile there.

[blizzz]

Command execution for created folders,

should work already

I can't see such trigger and it doesn't work for me with "File created"

You can limit the file type to directory. Unless your intention was to work on the parent directory of the affected file? This at least to some degree can be handled by the script called, but it could be done nicer of course.

Filtering by operation,

what do you mean?

There was probably no "When" for selecting triggers whet I raised this issue?

Possible. So, that's solved :)

Better path variable support for Local External Storages?

would you elaborate her as well?

User has external storage of type local: /home/userName mounted as /,
but for %n I get path like /userName/files/folderName/fileName.txt, which is not very handy.
Edit: %f does not work either and I don't like use of toTmpFile there.

%n is doing it correctly. %f is broken yet, but will see a fix with the upcoming release (planned tomorrow). You should see the absolute path in your case (expectation, I did not double check), the example temp name is expected when the file is taken from an external external(sic!) storage.

[army1349]

Command execution for created folders,

should work already

I can't see such trigger and it doesn't work for me with "File created"

You can limit the file type to directory. Unless your intention was to work on the parent directory of the affected file? This at least to some degree can be handled by the script called, but it could be done nicer of course.

That is OK. I want to detect both new files and directories and I have no problem with getting things like parent directory in script. Problem is that script is not triggered for new directories at all. I will try it again with new version.

Better path variable support for Local External Storages?

would you elaborate her as well?

User has external storage of type local: /home/userName mounted as /,
but for %n I get path like /userName/files/folderName/fileName.txt, which is not very handy.
Edit: %f does not work either and I don't like use of toTmpFile there.

%n is doing it correctly. %f is broken yet, but will see a fix with the upcoming release (planned tomorrow).

Perfect, I will test it then.

You should see the absolute path in your case (expectation, I did not double check), the example temp name is expected when the file is taken from an external external(sic!) storage.

Temp for external external (:D) storages makes sense.

[army1349]

I tested 1.5.1 version:

• Both %n and %f now contain full filesystem path for local storage, which works for me, but I don't know if it is intended behavior for %n.
• Script is not triggered by directory creation.

[blizzz]

%n should not return an absolute path when it is within the data directory. This is different for you?

Script is not triggered by directory creation.

Indeed, we are excluding folders. I would really love to answer you why, but this was like this since the very beginning, about two years ago, with the initial commit. Later one acutally a Folder is beign taken into consideration. So we may remove it. A quick smoke test went fine.

To unlock folders, the change is tiny:

diff --git a/lib/Operation.php b/lib/Operation.php
index 649d21f..40dfe7d 100644
--- a/lib/Operation.php
+++ b/lib/Operation.php
@@ -142,7 +142,7 @@ class Operation implements ISpecificOperation {
 
            // '', admin, 'files', 'path/to/file.txt'
            [, , $folder,] = explode('/', $node->getPath(), 4);
-           if ($folder !== 'files' || $node instanceof Folder) {
+           if ($folder !== 'files') {
                return;
            }

Maybe you want to try it out?

[army1349]

%n should not return an absolute path when it is within the data directory. This is different for you?

I have external local storage mounted as /, so it is specific case and I got full path for %n.
It could be useful to have username/files/path accessible via %n for something like occ files:scan --path ... call.

Script is not triggered by directory creation.

Indeed, we are excluding folders. I would really love to answer you why, but this was like this since the very beginning, about two years ago, with the initial commit. Later one acutally a Folder is beign taken into consideration. So we may remove it. A quick smoke test went fine.

To unlock folders, the change is tiny:

diff --git a/lib/Operation.php b/lib/Operation.php
index 649d21f..40dfe7d 100644
--- a/lib/Operation.php
+++ b/lib/Operation.php
@@ -142,7 +142,7 @@ class Operation implements ISpecificOperation {
 
            // '', admin, 'files', 'path/to/file.txt'
            [, , $folder,] = explode('/', $node->getPath(), 4);
-           if ($folder !== 'files' || $node instanceof Folder) {
+           if ($folder !== 'files') {
                return;
            }

Maybe you want to try it out?

Perfect! This works just fine.

[blizzz]

%n should not return an absolute path when it is within the data directory. This is different for you?

I have external local storage mounted as /, so it is specific case and I got full path for %n.
It could be useful to have username/files/path accessible via %n for something like occ files:scan --path ... call.

Yes, agreed.

Script is not triggered by directory creation.

Indeed, we are excluding folders. I would really love to answer you why, but this was like this since the very beginning, about two years ago, with the initial commit. Later one acutally a Folder is beign taken into consideration. So we may remove it. A quick smoke test went fine.
To unlock folders, the change is tiny:

diff --git a/lib/Operation.php b/lib/Operation.php
index 649d21f..40dfe7d 100644
--- a/lib/Operation.php
+++ b/lib/Operation.php
@@ -142,7 +142,7 @@ class Operation implements ISpecificOperation {
 
            // '', admin, 'files', 'path/to/file.txt'
            [, , $folder,] = explode('/', $node->getPath(), 4);
-           if ($folder !== 'files' || $node instanceof Folder) {
+           if ($folder !== 'files') {
                return;
            }

Maybe you want to try it out?

Perfect! This works just fine.

👍

[blizzz]

I think there is nothing left open here.