Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Distinguish "pin state flag" from "content availability" for directories #7111

Closed
ckamm opened this issue Mar 26, 2019 · 8 comments
Closed
Assignees
Labels
feature:vfs native virtual files and placeholder implementation
Milestone

Comments

@ckamm
Copy link
Contributor

ckamm commented Mar 26, 2019

A directory that's marked as "available locally" can nevertheless have files that are dehydrated or subfolders that are marked as "online only". This needs to be distinguished for icons (don't exist yet) and for context menu actions.

A full description for a folder would be:

  • new items are "always local", all contents are "always local"
  • new items are "always local", some files are dehydrated
  • new items are "always local" in this folder, but some subfolders are "online only", file hydration is mixed
  • and many more for the combinations of "online only" and "unspecified" pin state

That's too complex for users though. It's probably ok to simplify to:

  • "always local": it is pinned and all contents are hydrated. That means the user can rely on having data available locally.
  • "local": all contents are hydrated (but could be dehydrated by platform or client)
  • "some dehydrated": not all contents are available locally but it's not entirely unpinned - tells users that there's still some disk space that could be freed
  • "online only": it is unpinned and all contents are dehydrated (needs no disk space at all)
@ckamm ckamm added the feature:vfs native virtual files and placeholder implementation label Mar 26, 2019
@ckamm ckamm added this to the 2.6.0 milestone Mar 26, 2019
@ckamm ckamm self-assigned this Mar 26, 2019
ckamm added a commit that referenced this issue Apr 5, 2019
The idea is that the user's question is "is this folder's data available
offline?" and not "does this folder have AlwaysLocal pin state?".
The the answers to the two questions can differ: an always-local
folder can have subitems that are not always-local and are dehydrated.

The new availability enum intends to describe the answer to the user's
actual question and can be derived from pin states. If pin states aren't
stored in the database the way of calculating availability will depend
on the vfs plugin.
ckamm added a commit that referenced this issue Apr 8, 2019
The idea is that the user's question is "is this folder's data available
offline?" and not "does this folder have AlwaysLocal pin state?".
The the answers to the two questions can differ: an always-local
folder can have subitems that are not always-local and are dehydrated.

The new availability enum intends to describe the answer to the user's
actual question and can be derived from pin states. If pin states aren't
stored in the database the way of calculating availability will depend
on the vfs plugin.

NEEDS PLUGIN UPDATES
ckamm added a commit that referenced this issue Apr 9, 2019
The idea is that the user's question is "is this folder's data available
offline?" and not "does this folder have AlwaysLocal pin state?".
The the answers to the two questions can differ: an always-local
folder can have subitems that are not always-local and are dehydrated.

The new availability enum intends to describe the answer to the user's
actual question and can be derived from pin states. If pin states aren't
stored in the database the way of calculating availability will depend
on the vfs plugin.
ckamm added a commit that referenced this issue Apr 9, 2019
The idea is that the user's question is "is this folder's data available
offline?" and not "does this folder have AlwaysLocal pin state?".
The the answers to the two questions can differ: an always-local
folder can have subitems that are not always-local and are dehydrated.

The new availability enum intends to describe the answer to the user's
actual question and can be derived from pin states. If pin states aren't
stored in the database the way of calculating availability will depend
on the vfs plugin.
ckamm added a commit that referenced this issue Apr 9, 2019
The idea is that the user's question is "is this folder's data available
offline?" and not "does this folder have AlwaysLocal pin state?".
The the answers to the two questions can differ: an always-local
folder can have subitems that are not always-local and are dehydrated.

The new availability enum intends to describe the answer to the user's
actual question and can be derived from pin states. If pin states aren't
stored in the database the way of calculating availability will depend
on the vfs plugin.
@ckamm ckamm added the ReadyToTest QA, please validate the fix/enhancement label Apr 9, 2019
@HanaGemela
Copy link
Contributor

@michaelstingl when will we get documentation on VFS? I believe this has changes since March, the described wording does not match the current state

@ckamm
Copy link
Contributor Author

ckamm commented Jul 23, 2019

@HanaGemela The current wording (post-alpha2) is:

  • "Always available locally": item and all subitems are available, new files will start out hydrated, os will not dehydrate
  • "Currently available locally": item and all subitems are available, but at least one (sub?) item isn't pinned, so new files could start out dehydrated, or the os could dehydrate some items
  • "Some available online only": at least one subitem is dehydrated
  • "Available online only": item and all subitems are dehydrated

Doc on VFS: Yeah, it's time to write that. But even in 2.6 VFS will still be experimental and may still see large changes if we discover significant bugs or significant ways to enhance it.

@HanaGemela
Copy link
Contributor

@ckamm How to recreate "Currently available locally"? The below scenario doesn't work. How do I unpin a file?

  1. 'Always make available locally' against the parent folder
  2. 'Free up local space' against an item inside the folder
  3. Download that file by double clicking

@ckamm
Copy link
Contributor Author

ckamm commented Jul 24, 2019

@HanaGemela That's exactly how it should work and I've just verified it works on cfapi and suffix vfs. What happens when you do these steps?

I've noticed a bug with 0-byte files on cfapi - probably one that's really had to work around though, since the cfapi callbacks don't fire when a 0-byte file needs to be hydrated.

@HanaGemela
Copy link
Contributor

@ckamm when I run the steps the file is always available locally on macOS. For Windows it a mess as all files are pending...

@ckamm
Copy link
Contributor Author

ckamm commented Jul 24, 2019

@HanaGemela Maybe one of the other fixes has also affected this one. Try again tomorrow with a new build.

@HanaGemela
Copy link
Contributor

Icons will be dealt with in the issue #7291

Directories on Windows 10, client 2.6.0beta1 (build 12201):
Below is how owncloud status maps to availability status in the tooltip (@michaelstingl please confirm if you are happy with this wording and if so, this issue can be closed. Or should the status exactly match?)
Always available locally = Always available on this device
Currently available locally = Available on this device
Some available online only = Available when online
Available online only = Available when online

owncloud status on macOS 10.14.6, client 2.6.0beta1 (build 12261) matches Windows

@ckamm
Copy link
Contributor Author

ckamm commented Aug 12, 2019

@michaelstingl Please reopen if you disagree with the wording, see @HanaGemela's comment above.

@ckamm ckamm closed this as completed Aug 12, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature:vfs native virtual files and placeholder implementation
Projects
None yet
Development

No branches or pull requests

2 participants