dsoprea
set file's `trashed` attribute to true instead of permanently removing it
This is a PR for issue #177 I wasn't able to test it though, because I couldn't setup my debugging environment. Also, it is not configurable by FUSE variables yet.
So, if anybody is interested in this, please feel free to expand on this or provide me with suggestions on how to improve it :)
Thank you. It was a good suggestion and I was hoping to see a PR.
You can use Vagrant to easily test it (vagrant/).
GDFS needs to maintain its current behavior and permanently delete files unless you turn it on via mount variables.
Thanks for the vagrant hint. I tested it and found I used a deprecated method of trashing files, so I used the up-to-date function.
Concerning the variable: Would it be okay to use an environment variable like GD_DEBUG or do you prefer a FUSE variable? I'm asking since I don't have any experience with FUSE, so it could take a while until I can apply the changes.
Just consider it to be a mount parameter. It's not FUSE specific. These are the properties passed via "-o" when you mount any filesystem. This is necessary as probably no variables will be defined when filesystems are mounted at system startup.
Add a field to
https://github.com/dsoprea/GDriveFS/blob/master/gdrivefs/conf.py#L10 with a
default value of False and use conf.Conf.get('delete_to_trash') from
your patch to get the value. Update set to coerce the incoming string
value ("0", "1") to a bool (bool(int(value))) if key is equal to
"delete_to_trash".
On Apr 11, 2017 12:45 PM, "robeeeert" [email protected] wrote:
Thanks for the vagrant hint. I tested it and found I used a deprecated method of trashing files, so I used the up-to-date function.
Concerning the variable: Would it be okay to use an environment variable like GD_DEBUG or do you prefer a FUSE variable? I'm asking since I don't have any experience with FUSE, so it could take a while until I can apply the changes.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/dsoprea/GDriveFS/pull/178#issuecomment-293324165, or mute the thread https://github.com/notifications/unsubscribe-auth/AArrarWNCzcQlfMy25w_RdKrqfwiKd0fks5ru646gaJpZM4M5vrM .
Yea, makes sense! Thank you for your guidance! :)
One last question, out of curiosity: Why should the default behavior be to delete the files and not to trash them? Is it only backwards-compatibility or is it by design? I naively would argue it should default to trashing the files, since I don't see any downsides: Locally, the file is gone, but you still have the option to restore it from "the cloud", with "the cloud" acting as a backup system.
Can you please remove the comment at https://github.com/dsoprea/GDriveFS/blob/master/gdrivefs/gdfs/gdfuse.py#L670?
It was an oversight. Usually Unix filesystems at the console don't have a trash. On the other hand, maybe others assumed that it went into the trash but never mistakenly deleted anything important. For right now, let's just implement it and have some people test it. Then, we can adjust the default.
If a few people would like to volunteer to check that this works as expected, we can change the default after. Technically this is a break in backwards-compatibility, but since Google will GC the trashed items (and the quota won't be negatively affected for very long except for massive deletes, which is hardly the common use-case in GD) the risk is not very high.
Hey, just wanted to know if you're still into this thing and if you're content with the proposed approach :)
Hi again, I moved the method into its own module. Are you sure we need a class for it? I considered declaring it a static method, since we don't need any state (hardly ever in a utility class generally I guess), and then discovered the "python way" was to simply implement it as a normal function. What's your opinion on this?