GVFS Sparse prune after expected failure is successful but folders still present

Question

GVFS Sparse prune after expected failure is successful but folders still present

judemars opened this issue 5 years ago · 5 comments

I was testing what happened if I pruned a folder that was in use, and I saw this behavior:

Try to prune folder I'm in, fails as expected.
cd out of it
Try to prune same folder, succeeds but folders are still present on machine
Try to prune again, folders go away

I have a fairly stable repro right now if anyone wants me to demonstrate. I have added my diagnose at \scratch2\scratch\judemars\gvfs_20191107_173346.zip

D:\mono\src\engtools>gvfs sparse --set otools --prune

Running git status...Succeeded
Updating sparse folder set...Succeeded
Forcing a projection change...Succeeded
Finding folders to prune...Succeeded
Found 1 folders to prune.
Running git status before prune to make sure you don't have any pending changes.

Running git status...Succeeded

WARNING: If you abort the sparse after this point, the repo may become corrupt

Unmounting...Succeeded
Cleaning up folders...-Cannot prune folder 'engtools': removing 'engtools' failed.
Ensure no applications are accessing the folder and retry.
More details: The process cannot access the file 'D:\mono\src\engtools' because it is being used by another process.
Cleaning up folders...Succeeded
Mounting...Succeeded
engtools The process cannot access the file 'D:\mono\src\engtools' because it is being used by another process.
Failed to dehydrate 1 folder(s).
Failed to prune. Exit Code: DehydrateFolderFailures

D:\mono\src\engtools>cd ..

D:\mono\src>dir

Volume in drive D is Data
Volume Serial Number is B88B-F529

Directory of D:\mono\src

11/07/2019  05:26 PM    <DIR>          .
11/07/2019  05:26 PM    <DIR>          ..
<other files>
11/07/2019  05:24 PM    <DIR>          collateral
11/07/2019  05:24 PM    <DIR>          engtools
<other files>
11/04/2019  12:32 PM    <DIR>          otools
<other files>
11/07/2019  05:24 PM    <DIR>          warehouse
              7 File(s)         15,164 bytes
              6 Dir(s)  1,459,043,827,712 bytes free

\\ First of all, strange that only engtools failed but collateral and warehouse are still present

D:\mono\src>gvfs sparse --set otools --prune

Running git status...Succeeded
Updating sparse folder set...Succeeded
Forcing a projection change...Succeeded
Finding folders to prune...Succeeded
Found 1 folders to prune.
Running git status before prune to make sure you don't have any pending changes.

Running git status...Succeeded

WARNING: If you abort the sparse after this point, the repo may become corrupt

Unmounting...Succeeded
Cleaning up folders...Succeeded
Mounting...Succeeded
engtools folder prune successful.

D:\mono\src>dir

Volume in drive D is Data
Volume Serial Number is B88B-F529

Directory of D:\mono\src

11/07/2019  05:26 PM    <DIR>          .
11/07/2019  05:26 PM    <DIR>          ..
<other files>
11/07/2019  05:24 PM    <DIR>          collateral
11/07/2019  05:24 PM    <DIR>          engtools
<other files>
11/04/2019  12:32 PM    <DIR>          otools
<other files>
11/07/2019  05:24 PM    <DIR>          warehouse
              7 File(s)         15,164 bytes
              6 Dir(s)  1,459,043,827,712 bytes free

\\ This is the bug, only the otools directory should be present here
\\ However, rerunning gvfs sparse fixes the issue:

D:\mono\src>gvfs sparse --set otools --prune

Running git status...Succeeded
Updating sparse folder set...Succeeded
Forcing a projection change...Succeeded
Finding folders to prune...Succeeded
Found 0 folders to prune.

D:\mono\src>dir

 Volume in drive D is Data
 Volume Serial Number is B88B-F529

 Directory of D:\mono\src

11/07/2019  05:28 PM    <DIR>          .
11/07/2019  05:28 PM    <DIR>          ..
<other files>
11/04/2019  12:32 PM    <DIR>          otools
11/07/2019  05:24 PM             6,725 tagger_config.json

Answer 1 · 2019-11-25T20:40:04.000Z

@judemars I'm unable to repro this issue with my changes in #1605

I will assign this issue over to you, could you re-test this scenario on your machine once a new release with #1605 is ready?

Answer 2 · 2019-12-10T05:38:57.000Z

Sadly, this does still repro for me on the new version of gvfs. Please note that engtools is a folder with multiple subfolders in the original sparse list within it - I think that may be causing the problem?
D:\mono\src>gvfs sparse --list

buildengine
cbtoolsnative
cbtoolssetup
cloudbuildtools
collateral
domino
dominotools\graphquery
engtools\basebranchfinder
engtools\binarystore
engtools\hydrate
engtools\importexport
engtools\officepackages
engtools\opm
engtools\pecomp
engtools\projects
engtools\qtstore
engtools\smartcopy
nmake
otools
pkgnuget\cloudbuildtools
pkgnuget\msbuildshared
warehouse

D:\mono\src>dir

 Volume in drive D is Data
 Volume Serial Number is B88B-F529

 Directory of D:\mono\src

12/09/2019  09:27 PM    <DIR>          .
12/09/2019  09:27 PM    <DIR>          ..
12/09/2019  08:39 PM    <DIR>          buildengine
12/09/2019  08:39 PM    <DIR>          cbtoolsnative
12/09/2019  08:39 PM    <DIR>          cbtoolssetup
12/09/2019  08:39 PM    <DIR>          cloudbuildtools
12/09/2019  08:39 PM    <DIR>          collateral
12/09/2019  08:39 PM    <DIR>          domino
12/09/2019  09:27 PM    <DIR>          dominotools
12/09/2019  09:27 PM    <DIR>          engtools
12/09/2019  08:39 PM    <DIR>          nmake
11/15/2019  03:32 PM    <DIR>          otools
12/09/2019  09:27 PM    <DIR>          pkgnuget
12/09/2019  08:39 PM    <DIR>          warehouse
               7 File(s)         15,164 bytes
              14 Dir(s)  1,395,597,340,672 bytes free

D:\mono\src>cd engtools

D:\mono\src\engtools>gvfs sparse --set otools --prune

Running git status...Succeeded
Updating sparse folder set...Succeeded
Forcing a projection change...Succeeded
Finding folders to prune...Succeeded
Found 1 folders to prune.

WARNING: If you abort the sparse after this point, the repo may become corrupt

Unmounting...Succeeded
Cleaning up folders...-Cannot prune folder 'engtools': removing 'engtools' failed.
Ensure no applications are accessing the folder and retry.
More details: The process cannot access the file 'D:\mono\src\engtools' because it is being used by another process.
Cleaning up folders...Succeeded
Mounting...Succeeded
engtools The process cannot access the file 'D:\mono\src\engtools' because it is being used by another process.
Failed to dehydrate 1 folder(s).
Failed to prune. Exit Code: DehydrateFolderFailures

D:\mono\src\engtools>cd ..

(Note this is a departure from before - here there were some folders present other than what got succesfully dehydrated)
D:\mono\src>dir

 Volume in drive D is Data
 Volume Serial Number is B88B-F529

 Directory of D:\mono\src

12/09/2019  09:28 PM    <DIR>          .
12/09/2019  09:28 PM    <DIR>          ..
12/09/2019  09:27 PM    <DIR>          engtools
11/15/2019  03:32 PM    <DIR>          otools
               7 File(s)         15,164 bytes
               4 Dir(s)  1,395,597,185,024 bytes free

D:\mono\src>gvfs sparse --set otools --prune

Running git status...Succeeded
Updating sparse folder set...Succeeded
No folders to update in sparse set.
Finding folders to prune...Succeeded
Found 1 folders to prune.

WARNING: If you abort the sparse after this point, the repo may become corrupt

Unmounting...Succeeded
Cleaning up folders...Succeeded
Mounting...Succeeded
engtools folder prune successful.

D:\mono\src>dir

 Volume in drive D is Data
 Volume Serial Number is B88B-F529

 Directory of D:\mono\src

12/09/2019  09:29 PM    <DIR>          .
12/09/2019  09:29 PM    <DIR>          ..
12/09/2019  08:39 PM    <DIR>          buildengine
12/09/2019  08:39 PM    <DIR>          cbtoolsnative
12/09/2019  08:39 PM    <DIR>          cbtoolssetup
12/09/2019  08:39 PM    <DIR>          cloudbuildtools
12/09/2019  08:39 PM    <DIR>          collateral
12/09/2019  08:39 PM    <DIR>          domino
12/09/2019  09:29 PM    <DIR>          dominotools
12/09/2019  09:29 PM    <DIR>          engtools
12/09/2019  08:39 PM    <DIR>          nmake
11/15/2019  03:32 PM    <DIR>          otools
12/09/2019  09:29 PM    <DIR>          pkgnuget
12/09/2019  08:39 PM    <DIR>          warehouse
               7 File(s)         15,164 bytes
              14 Dir(s)  1,395,597,111,296 bytes free

D:\mono\src>gvfs sparse --set otools --prune

Running git status...Succeeded
Updating sparse folder set...Succeeded
Forcing a projection change...Succeeded
Finding folders to prune...Succeeded
Found 0 folders to prune.

D:\mono\src>dir

 Volume in drive D is Data
 Volume Serial Number is B88B-F529

 Directory of D:\mono\src

12/09/2019  09:29 PM    <DIR>          .
12/09/2019  09:29 PM    <DIR>          ..
11/15/2019  03:32 PM    <DIR>          otools
12/09/2019  08:39 PM             6,725 tagger_config.json
               7 File(s)         15,164 bytes
               3 Dir(s)  1,395,596,947,456 bytes free

D:\mono\src>gvfs --version

GVFS 0.3.19330.1

Answer 3 · 2019-12-11T19:09:14.000Z

@judemars to confirm, it looks like the unexpected behavior is seeing a bunch of the folders after running gvfs sparse --set otools --prune again from inside src? Does that sound right to you?

Answer 4 · 2019-12-11T20:58:23.000Z

@wilbaker yes! After the second gvfs sparse --set otools --prune call, which says it was successful, there should only be the otools directory present in src. After the third call, this seems to be the case.

Answer 5 · 2019-12-12T23:11:20.000Z

This turned out to be a problem on my end - the reset that is called during gvfs sparse was triggering the git hook we are using to update the sparse list to be a different set than otools. Will fix on our end. Thanks for the debugging help William!