Add recursiveFileCount & recursiveFolderCount fields to Drive API [154960927]

Assigned

Feature Request

Status Update

No update yet.

Description

an...@gmail.com

created issue #1

Apr 25, 2020 09:55AM

Before filing an issue, please read and follow these instructions carefully.

First, please search through existing issues to ensure that the feature request has not already been reported. You can start the search here:

https://issuetracker.google.com/savedsearches/566258

If the feature has already been requested, you can click the star next to the issue number to subscribe and receive updates. We prioritize responding to the issues with the most stars. You can also comment on the issue to provide any context of how the feature would benefit you.

Also, please verify that the functionality you are requesting is not already present in the current API and tools.

If your feature has not been requested, please provide all of the following:
-----------------------------------------------------------------------------------------------------------------------------
A short description of the request:

Add recursiveFileCount & recursiveFolderCount fields to the public Drive API.

What is the purpose of this new feature?

Add recursiveFileCount & recursiveFolderCount fields to the public Drive API

What existing APIs would this affect?

Drives Get API, specifically the Drives resource that is returned.

What existing data does this use?

recursiveFileCount & recursiveFolderCount fields

Please provide any additional information below.

These fields are already present in the internal API used by the browser and will be very useful in determining when a shared drive is close to its 400k file+folder limit without needing to count all the items manually.

Comments

ja...@google.com <ja...@google.com> Apr 27, 2020 07:14AM

Assigned to ja...@google.com.

ja...@google.com <ja...@google.com> #2Apr 27, 2020 08:33AM

Status: Won't Fix (Infeasible)

Thank you for the report, and sorry for any inconvenience. While reproducing the issue, one workaround I found is: -keeppackagenames com.example.customview.extra** (i.e., double asterisks, instead of single).

https://www.guardsquare.com/en/products/proguard/manual/usage#filters

R8 currently regards <package_filter> in that directive as <class_filter>. That's why single asterisk---a class name not containing the package separator---doesn't work for now, whereas double asterisks---matches a class name, possibly containing any number of package separators---works. The caveat is, use of, e.g., extra**, will keep all the sub packages as well. :( We'll prepare the fix soon.

an...@gmail.com <an...@gmail.com> #3Apr 27, 2020 09:35AM

Project: r8
Branch: master

commit a9a9e7d1231726094c6e16c2cef1bad887da3bba
Author: Jinseong Jeon <jsjeon@google.com>
Date: Tue Apr 09 11:49:28 2019

Reproduce

b/130135768

: keeppackagenames with asterisks

Bug: 130135768
Change-Id: I5ab1cdb5148a570a63bdd488358759bb33da700a

M src/test/java/com/android/tools/r8/TestShrinkerBuilder.java
A src/test/java/com/android/tools/r8/naming/KeepPackageNamesTest.java
A src/test/java/com/android/tools/r8/naming/keeppackagenames/Top.java
A src/test/java/com/android/tools/r8/naming/keeppackagenames/sub/SubClass.java

https://r8-review.googlesource.com/36860

ja...@google.com <ja...@google.com> #4Apr 27, 2020 11:48AM

Status: Assigned (reopened)

Project: r8
Branch: master

commit 391e2992aee375adf46edbb5e7b098556c8604ed
Author: Søren Gjesse <sgjesse@google.com>
Date: Fri Apr 12 11:05:43 2019

New implementation of -keeppackagenames

This implementation collects the list of package names given for
-keeppackagenames and matches against that in the minifier.

The previous implementation created class matching rules to piggybag
on the existing matching.

Bug: 130135768
Change-Id: I5a341e145747a5dec8788a066a0c67d4e259ec77

M src/main/java/com/android/tools/r8/graph/DexType.java
M src/main/java/com/android/tools/r8/naming/ClassNameMinifier.java
M src/main/java/com/android/tools/r8/shaking/ProguardConfiguration.java
M src/main/java/com/android/tools/r8/shaking/ProguardConfigurationParser.java
D src/main/java/com/android/tools/r8/shaking/ProguardKeepPackageNamesRule.java
A src/main/java/com/android/tools/r8/shaking/ProguardPackageMatcher.java
A src/main/java/com/android/tools/r8/shaking/ProguardPackageNameList.java
M src/main/java/com/android/tools/r8/shaking/RootSetBuilder.java
M src/test/java/com/android/tools/r8/naming/KeepPackageNamesTest.java
M src/test/java/com/android/tools/r8/shaking/ProguardConfigurationParserTest.java
A src/test/java/com/android/tools/r8/shaking/ProguardPackageNameMatcherTest.java

https://r8-review.googlesource.com/36944

an...@gmail.com <an...@gmail.com> #5Apr 27, 2020 11:57AM

Project: r8
Branch: d8-1.4

commit b6ca9ee953e43aa029411bb4db030e4694180063
Author: Christoffer Quist Adamsen <christofferqa@google.com>
Date: Fri Apr 12 12:51:40 2019

Version 1.4.86

Cherry pick: New implementation of -keeppackagenames
CL:

https://r8-review.googlesource.com/c/r8/+/36944

Cherry pick: Reproduce

b/130135768

: keeppackagenames with asterisks
CL:

https://r8-review.googlesource.com/c/r8/+/36860

Bug: 130135768
Change-Id: I8a340afe4811ec3f8826956c99b94346f4c2c8b4

M src/main/java/com/android/tools/r8/Version.java
M src/main/java/com/android/tools/r8/graph/DexType.java
M src/main/java/com/android/tools/r8/naming/ClassNameMinifier.java
M src/main/java/com/android/tools/r8/shaking/ProguardConfiguration.java
M src/main/java/com/android/tools/r8/shaking/ProguardConfigurationParser.java
D src/main/java/com/android/tools/r8/shaking/ProguardKeepPackageNamesRule.java
A src/main/java/com/android/tools/r8/shaking/ProguardPackageMatcher.java
A src/main/java/com/android/tools/r8/shaking/ProguardPackageNameList.java
M src/main/java/com/android/tools/r8/shaking/RootSetBuilder.java
M src/test/java/com/android/tools/r8/TestShrinkerBuilder.java
A src/test/java/com/android/tools/r8/naming/KeepPackageNamesTest.java
A src/test/java/com/android/tools/r8/naming/keeppackagenames/Top.java
A src/test/java/com/android/tools/r8/naming/keeppackagenames/sub/SubClass.java
M src/test/java/com/android/tools/r8/shaking/ProguardConfigurationParserTest.java
A src/test/java/com/android/tools/r8/shaking/ProguardPackageNameMatcherTest.java

https://r8-review.googlesource.com/36959

ja...@google.com <ja...@google.com> #6Apr 30, 2020 12:59PM

Hello!

Could you specify the business reason (impact on revenue, costs, or employee productivity), and if using "Space used" in Apps >G Suite > Settings for Drive and Docs > Manage shared drives from the Admin Consolewould fit your needs?

Thanks

an...@gmail.com <an...@gmail.com> #7Apr 30, 2020 02:26PM

Could you specify the business reason (impact on revenue, costs, or employee productivity)

This would greatly simplify the existing code and also reduce the required API calls by a lot to get the required info. The current implementation requires us to do multiple list queries to fetch all the objects and also takes a lot of time to finish on larger drives.

As a result of the significant simplification of the drive limit calculation, this will make many applications more efficient, thus reducing costs.

if using "Space used" in Apps >G Suite > Settings for Drive and Docs > Manage shared drives from the Admin Console

This requires admin access which is not feasible to give to everyone in the domain just to know the shared drive file & folder counts.

Message last modified on Apr 30, 2020 08:25PM

ja...@google.com <ja...@google.com> #8May 1, 2020 10:18AM

Thanks for the information!

ch...@zenbusiness.com <ch...@zenbusiness.com> #9Mar 23, 2023 05:06PM

We currently hit a limit on a shared drive that caused work stoppage for approximately 150 users.
Not only is there no indication of item count but there is no way to alert if you are getting near the 400K threshold.
Administrators absolutely need to have this feature.
- API hooks to read item count
- Item Counts displayed throughout the directory tree
Additionally - it would be nice to have alerting and even auto archiving capacity

[Deleted User] <[Deleted User]> #10Apr 11, 2023 12:08PM

We're in the same situation, it needs alerting and/or a way to check this through the API

is...@google.com <is...@google.com> May 17, 2023 07:14AM

Status: New

ma...@iob.ch <ma...@iob.ch> #11May 17, 2023 01:53PM

+1 for this as it is explained in comments #9 and #10

jv...@campbellmarketing.com <jv...@campbellmarketing.com> #12May 17, 2023 02:13PM

+1 -- this has been an issue for a number of years for us. this would be a welcome improvement - especially if we could incorporate Rules based alerts for it -- help avoid the "lock out" situation.

[Deleted User] <[Deleted User]> #13May 19, 2023 12:27PM

jp...@google.com <jp...@google.com> Jul 13, 2023 02:38AM

Assigned to wo...@google.com.

ae...@bizcap.com.au <ae...@bizcap.com.au> #14Mar 12, 2024 11:55PM

+1, the issue hits us out of nowhere and we need to stop operations and move files around