nielash 9b4b3033da fs/cache: fix parent not getting pinned when remote is a file ... Before this change, when cache.GetFn was called on a file rather than a directory, two cache entries would be added (the file + its parent) but only one of them would get pinned if the caller then called Pin(f). This left the other one exposed to expiration if the ci.FsCacheExpireDuration was reached. This was problematic because both entries point to the same Fs, and if one entry expires while the other is pinned, the Shutdown method gets erroneously called on an Fs that is still in use. An example of the problem showed up in the Hasher backend, which uses the Shutdown method to stop the bolt db used to store hashes. If a command was run on a Hasher file (ex. `rclone md5sum --download hasher:somelargefile.zip`) and hashing the file took longer than the --fs-cache-expire-duration (5m by default), the bolt db was stopped before the hashing operation completed, resulting in an error. This change fixes the issue by ensuring that: 1. only one entry is added to the cache (the file's parent, not the file). 2. future lookups correctly find the entry regardless of whether they are called with the parent name or one of its children. 3. fs.ErrorIsFile is returned when (and only when) fsString points to a file (preserving the fix from 8d5bc7f28b). Note that f.Root() should always point to the parent dir as of c69eb84573		2024-09-28 13:49:56 +01:00
..
cache_test.go	fs/cache: fix parent not getting pinned when remote is a file	2024-09-28 13:49:56 +01:00
cache.go	fs/cache: fix parent not getting pinned when remote is a file	2024-09-28 13:49:56 +01:00