-
Notifications
You must be signed in to change notification settings - Fork 47
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
Overwrite control #230
Comments
The troubling thing about |
My head is very far away from this right now but a quick reaction:
Here's why it's not a no-brainer for I'm happy to make some usability improvements, but hopefully this gives you more context for the way things currently are. Can you refine the wish list in light of this? |
re: the difference in parameters
We tried to be consistent in these parameter names such that when it is referencing an actual file we use |
re: @jennybc @LucyMcGowan I know that the google api is not a normal file system, yet my workflow is organized in a way assuming that it is. Most data on my google drive is organized in hierachical folders and I usually want to update a specific file in a specific folder. As mentioned by @DataStrategist as well I think that I think the functionality that I am missing in My current workflow looks like this:
As mentioned in the beginning, this is only a suggestion. Thanks for all your work on the |
Actually @Martin-Jung I think when you say
that's not correct. My use case is that I have a process that Therefore, in order to emulate that behavior, I think However, @jennybc if you want to keep it as is, perhaps at very least when a user uploads something that already exists on the drive there should be a warning saying "By the way user, since that filename already existed and google drive is a crazy filesystem, I have created another file with that name"... just because perhaps having one filename is behavior that a reasonable user might expect? 😄 FWIW, I fixed the problem by |
Having just skimmed this and some other issues, I feel like an
|
Hello People of Issue #230! I'm working on a large PR (#266) that adds an And aided by that infrastructure and mindset, I've been able to add a new function:
which, in pseudo-code, does this:
I'm not done yet, but I am to the point where input from people who try it and care about this stuff would be very useful. Here's how to install from that PR:
|
Cheers @jennybc , 👍
|
So does |
It does. The feature that I was specifically missing was a function to update an existing file on google drive. The |
* Refactor to reveal similarity in these functions * Devote less attention to parent edge cases In previous refactoring commit, I stopped checking whether both `path` and `parents` were specified in `drive_upload()`. I claim this is incredibly rare and not worth the code and headspace to maintain. Let the behaviour be undefined / undescribed and, if it is wrong or surprising and actually matters, someone will speak up. * Don't try to delete a file more than once Tests added in the next commit revealed that, for filepath input to `drive_rm()`, we tried to delete each file n times, where n = the number of filepaths for that file. n can be greater than 1 if a file has multiple parents. * Test that drive_update() can add a parent folder I am removing checks and tests around unusual parent situations elsewhere. I intend to send people to drive_update() for all weird parent folder situations. So I want an explicit test that you can add a parent folder this way. * Centralize more path handling * Use rationalize_path_name() * Deprecate `parent`, in favor of `path` Revisit this later with lifecycle * Changes in drive_create() mean this test hits the API now * Test rationalize_path_name() * Introduce `overwrite` Closes #230 * Oops forgot drive_rename() * Add NEWS section * Oops, forgot drive_mv() * Test check_for_overwrite() and, therefore, the `overwrite` arguments * No, really, `parent` is a file ID Refine tests * Show `overwrite` in examples * Add handy "recency" example for drive_find() * Tweak NEWS * Extract overwrite_hits() * Maybe it's a little aggressive/dangerous to empty trash here But I have seen that the presence of files on Drive, in the trash, can affect tests. Tests should technically leave the trash the way the found it and be "trash-aware". But sometimes it's easiest to just clean it out. * Add drive_put() Truly closes #230 * Test for drive_put() * More doc updates re: drive_put() * Put in the usual skips * Add "local" now that so many other functions deal in a "remote" overwrite
Two minor things:
Can the parameter to the local file for
drive_update()
be harmonized with the parameter fordrive_upload()
? Currently the former is called "file" and the latter is called "path". Somewhat confusing...Would it be possible to have an "overwrite = TRUE" parameter in
drive_upload
? Or alternatively enable a fallback option (parameter "create = TRUE") indrive_update()
so that it creates files instead of raising an error if the file is not existing. Or combine both functions into one ?The text was updated successfully, but these errors were encountered: