# revisiting empty option for file module **URL:** \ **Category:** Ansible Developer\ **Created:** [July 28, 2020, 3:50pm UTC](https://forum.ansible.com/t/revisiting-empty-option-for-file-module/33512 "2020-07-28T15:50:05Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![rjwagner.dba](https://avatars.discourse-cdn.com/v4/letter/r/e8c25b/32.png) [@rjwagner.dba](https://forum.ansible.com/u/rjwagner.dba)\ **Post date:** [July 28, 2020, 3:50pm UTC](https://forum.ansible.com/t/revisiting-empty-option-for-file-module/33512/1 "2020-07-28T15:50:05Z")
Hey all - a while back, it looks like someone proposed a feature request to add an “empty” option to the file module that would allow one to remove the _contents_ of a directory but leave the directory alone. A PR [https://github.com/ansible/ansible-modules-core/pull/5652](https://github.com/ansible/ansible-modules-core/pull/5652) was submitted and then dismissed by the Core team (Brian?). I don’t think the original contributor ever followed up here, so I will. I understand two workarounds have been proposed: 1. note directory ownership and permissions, delete the directory and recreate it with appropriate ownership/permissions 2. use the find module to get the contents of the directory, and then use the file module to delete the contents as provided by find. 1, in my opinion, is a non-starter, simply because it is not idempotent. If a failure occurs after the directory is deleted, we cannot recreate it with its original ownership and permissions. Even if we rerun the playbook, once the directory is gone, it’s ownership/permissions are lost. 2 is viable, and it’s what we currently do, but it is inefficient, especially for directories with large numbers of files/subdirectories. If you have thousands (or more) of files/subdirectories, find has to send all that back to the control machine, and then that huge payload has to get sent off to file, and all the output for each individual deletion has to come back to the control host. What are the Core team’s concerns about the PR or the feature request? If the PR is problematic, I will reach out to the original author or I, myself, will revisit it, but if the feature request, itself, is a non-starter, I’d really like to understand why. Thanks Rob ---
**Author:** ![rjwagner.dba](https://avatars.discourse-cdn.com/v4/letter/r/e8c25b/32.png) [@rjwagner.dba](https://forum.ansible.com/u/rjwagner.dba)\ **Post date:** [August 2, 2020, 4:59pm UTC](https://forum.ansible.com/t/revisiting-empty-option-for-file-module/33512/2 "2020-08-02T16:59:05Z")
Hey all - any comments on an empty option for the file module? Anyone know why the earlier PR was rejected? Rob ---
**Author:** ![tkuratom](https://avatars.discourse-cdn.com/v4/letter/t/b19c9b/32.png) [@tkuratom](https://forum.ansible.com/u/tkuratom)\ **Post date:** [August 4, 2020, 3:05pm UTC](https://forum.ansible.com/t/revisiting-empty-option-for-file-module/33512/3 "2020-08-04T15:05:45Z")
I don't have answers to your question but I wonder about your use case. Directories are seldom left empty so it seems like this is more about taking action to empty a directory than it does to assert that the state of the system includes the emptied directory. That can be an important distinction as taking action can be done with the shell and command modules. For instance: - shell: "rm -rf {{ directory }}/\*" If you really are asserting that the directory exists in an emptied state on the system, then something in a module makes sense as the module can return whether it made a change or the system was already in the desired state. -Toshio