ERROR: 403: shortcutTargetInvalid - The specified file is not an allowed shortcut target type.

[gns-jdaniel]

Ran the following command:

gam user [email] move drivefile "[drivefileid]" teamdriveparentid "[teamdriveid]" newfilename "Transferred Files v2" createshortcutsfornonmovablefiles true

It chugged along for 20 minutes or so, and then the process halted before it was finished with the following error message: "ERROR: 403: shortcutTargetInvalid - The specified file is not an allowed shortcut target type."

Unfortunately, I don't get anything helpful like a filename or file ID, but it looks like it MIGHT be a shortcut (application/vnd.google-apps.shortcut)

[gns-jdaniel]

To be clear: the command successfully copied hundreds of files and folders before hitting this error. The enclosing folder it was processing when it died is owned by an outside organization. The shortcuts look to have been followed rather than copied themselves (ie mystery files were copied that turned out to be the linked DOC files, rather than the application/vnd.google-apps.shortcut files).

I suspect that the error is coming from one of these shortcut files that was followed rather than copied.

Is it possible to use "createshortcutsfornonmovablefiles true" as well as some sort of "don't follow shortcuts and copy the original, just copy the shortcut itself" flag?

[gns-jdaniel]

I see there's "copiedshortcutspointtocopiedfiles false", but that gives me an error when I add it to the end of my command

[taers232c]

Send me a Meet/Zoom invitation.

Ross

On Wed, Jul 13, 2022 at 9:20 AM gns-jdaniel @.***> wrote:

I see there's "copiedshortcutspointtocopiedfiles false", but that gives me an error when I add it to the end of my command

— Reply to this email directly, view it on GitHub https://github.com/taers232c/GAMADV-XTD3/issues/284#issuecomment-1183424971, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCTYL3W6UCR536MQYIMNN3VT3UFPANCNFSM53M3KDRA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

-- Ross Scroggs @.***

[taers232c]

Fixed 6.24.21

[gns-jdaniel]

Thank you very much for fixing this so quickly!

It was a pleasure speaking with you today about the problem and its resolution.

[taers232c]

Does this mean that the re-run of the updated command worked?

Inquiring minds want to know.

How many files were left behind?

On Wed, Jul 13, 2022 at 4:13 PM gns-jdaniel @.***> wrote:

Thank you very much for fixing this so quickly!

It was a pleasure speaking with you today about the problem and its resolution.

— Reply to this email directly, view it on GitHub https://github.com/taers232c/GAMADV-XTD3/issues/284#issuecomment-1183770406, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCTYLYWKJBYJYCLZE5SCB3VT5EQHANCNFSM53M3KDRA . You are receiving this because you modified the open/close state.Message ID: @.***>

-- Ross Scroggs @.***

[gns-jdaniel]

I believe it did work, just as you expected. I first manually combined an old move that I'd trashed, thinking it would simply re-move the files (which were actually deleted once they were moved). Then I ran the command you suggested (with the teamdriveparentid replaced with the new folder ID rather than the teamdrive root ID) and it's still running as I type this...no more error 403s!

Thanks again!

[gns-jdaniel]

One more question - in my revised GAM command, I added "excludetrashed", because I saw a lot of log messages about the item not being included because it was in the Trash...and it is a legit flag...but it gives an error when I run this:

gam user [user_email] move drivefile "original_folder_id" teamdriveparentid "destination_folder_id" createshortcutsfornonmovablefiles true mergewithparent true excludetrashed

I just ended up removing excludetrashed, but it looked like it should have worked, and maybe would have omitted all the "not done because it's in Trash" messages.

[taers232c]

Send Meet/Zoom invitation.

Ross

On Thu, Jul 14, 2022 at 9:49 AM gns-jdaniel @.***> wrote:

One more question - in my revised GAM command, I added "excludetrashed", because I saw a lot of log messages about the item not being included because it was in the Trash...and it is a legit flag...but it gives an error when I run this:

gam user [user_email] move drivefile "original_folder_id" teamdriveparentid "destination_folder_id" createshortcutsfornonmovablefiles true mergewithparent true excludetrashed

I just ended up removing excludetrashed, but it looked like it should have worked, and maybe would have omitted all the "not done because it's in Trash" messages.

— Reply to this email directly, view it on GitHub https://github.com/taers232c/GAMADV-XTD3/issues/284#issuecomment-1184667560, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCTYL5XMX5YQZ43EPJQL4DVUBAINANCNFSM53M3KDRA . You are receiving this because you modified the open/close state.Message ID: @.***>

-- Ross Scroggs @.***

[gns-jdaniel]

It took a while to interpret the results of

gam user [user_email] print filelist select id:[folder_id] anyowner allfields todrive

but it looks like the massive file list is all stuff inside trashed folders...so the files are not explicitly trashed themselves, but contained within trashed folders and therefore not moved to the shared drive.

In the future, I think I'll use explicit fields rather than allfields:

fields id,name,explicitlyTrashed,fullFileExtension,mimeType,parents.0.id,owners.0.emailAddress,owners.0.me,capabilities.canMoveItemIntoTeamDrive,capabilities.canCopy,createdTime,shortcutDetails.targetId,shortcutDetails.targetMimeType

Are there any other fields that might be useful for moving files, in your opinion?

[taers232c]

Send Meet invitation.

Ross

On Thu, Jul 14, 2022 at 11:14 AM gns-jdaniel @.***> wrote:

It took a while to interpret the results of

gam user [user_email] print filelist select id:[folder_id] anyowner allfields todrive

but it looks like the massive file list is all stuff inside trashed folders...so the files are not explicitly trashed themselves, but contained within trashed folders and therefore not moved to the shared drive.

In the future, I think I'll use explicit fields rather than allfields:

fields id,name,explicitlyTrashed,fullFileExtension,mimeType,parents.0.id ,owners.0.emailAddress,owners.0.me,capabilities.canMoveItemIntoTeamDrive,capabilities.canCopy,createdTime,shortcutDetails.targetId,shortcutDetails.targetMimeType

Are there any other fields that might be useful for moving files, in your opinion?

— Reply to this email directly, view it on GitHub https://github.com/taers232c/GAMADV-XTD3/issues/284#issuecomment-1184754931, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCTYL6WS2FNP4LSYHOJFITVUBKG3ANCNFSM53M3KDRA . You are receiving this because you modified the open/close state.Message ID: @.***>

-- Ross Scroggs @.***

[gns-jdaniel]

To reiterate our conversation: the "trashed" flag field for items contained within a trashed folder is showing as "FALSE". The enclosing folder is "explicitlyTrashed=TRUE,trashed=TRUE", but the items within it are "explicitlyTrashed=FALSE,trashed=FALSE", when they should be "explicitlyTrashed=FALSE,trashed=TRUE".

Perhaps this is why they get logged during a mydrive-shareddrive move as "not copied because in trash".

[taers232c]

Send me a Meet invitation and we'll talk trash.

Ross

On Thu, Jul 14, 2022 at 12:06 PM gns-jdaniel @.***> wrote:

To reiterate our conversation: the "trashed" flag field for items contained within a trashed folder is showing as "FALSE". The enclosing folder is "explicitlyTrashed=TRUE,trashed=TRUE", but the items within it are "explicitlyTrashed=FALSE,trashed=FALSE", when they should be "explicitlyTrashed=FALSE,trashed=TRUE".

Perhaps this is why they get logged during a mydrive-shareddrive move as "not copied because in trash".

— Reply to this email directly, view it on GitHub https://github.com/taers232c/GAMADV-XTD3/issues/284#issuecomment-1184798549, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCTYL7EFFRRN5MXAVZ7D2LVUBQLPANCNFSM53M3KDRA . You are receiving this because you modified the open/close state.Message ID: @.***>

-- Ross Scroggs @.***

[taers232c]

I've joined

On Fri, Jul 15, 2022 at 10:32 AM gns-jdaniel @.***> wrote:

I love trash-talkin'! :)

https://meet.google.com/djh-hytu-zwr

— Reply to this email directly, view it on GitHub https://github.com/taers232c/GAMADV-XTD3/issues/284#issuecomment-1185755773, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCTYL5WXPRBUQ2G5XG6QZLVUGODRANCNFSM53M3KDRA . You are receiving this because you modified the open/close state.Message ID: @.***>

-- Ross Scroggs @.***

[gns-jdaniel]

I had misinterpreted the zillion columns produced by the allfields flag when I ran the filelist, and misreported that the documents themselves were coming up "explicitlyTrashed=FALSE,trashed=FALSE".

You noticed that since Google recursively processed the Trashed flag on folder contents, sometimes it's possible to see this behaviour within a very short period of time after deleting the folder...but then get set correctly.

In fact, my files WERE trashed - I just misread the columns, since I had run the filelist the next morning, and there was no way Google would be that slow to update the Trashed flag.

Thank you for spending the time researching my wild goose chase - sorry for wasting your time! (but thanks very much for patiently explaining everything in detail!)