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

Preserve mtime, etag #83

Closed
PVince81 opened this issue Apr 11, 2022 · 4 comments
Closed

Preserve mtime, etag #83

PVince81 opened this issue Apr 11, 2022 · 4 comments
Assignees
Milestone

Comments

@PVince81
Copy link
Member

Preserve more file metadata like mtime and etag.

Not preserving leads to apps like recommendations thinking that all files are new and then recommends them all.

This is also important in case the user has local data and they simply reconfigure their desktop client to point at the new account and keep the local data. I believe that having a different mtime would cause the desktop client to redownload all files while having the same mtime would keep them. (I was able to keep the local files with a new account yesterday, that's how I know!)

@PVince81 PVince81 mentioned this issue Apr 11, 2022
5 tasks
@come-nc
Copy link
Collaborator

come-nc commented Apr 11, 2022

Questions:

  • How? Node (parent class of Folder/File) has getMTime and getEtag but no setter function than I can see. Do we have any code messing with mtime or etag currently?
  • Is it safe and will the instance behave correctly with files that appears to be older than its installation?
  • Attack vector? Do we need to protect against really old date or future date?

@PVince81 PVince81 self-assigned this Apr 11, 2022
@PVince81
Copy link
Member Author

@come-nc good points.

for the mtime, we can use `touch()' as in #84

the instance will behave fine.
even now it is possible to upload files with an mtime in the past

regarding bogus mtimes, I'd assume that instances that have them are already fixed by now.
otherwise, we could at least enforce that mtime > 0 +24h (the value 0, epoch) like we do in some places

@PVince81
Copy link
Member Author

for etag, it's a different discussion which I'm afraid will be much more complicated
keeping etags will likely not be necessary because the user will need to setup the desktop client from scratch for the new account, and for new accounts the client doesn't know any etags, so they are not relevant

@PVince81 PVince81 added this to the 0.1 milestone Apr 12, 2022
@PVince81
Copy link
Member Author

I don't think we should preserve etags because of the above reason.

mtime preservation has been merged, closing

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants