Cannot delete directory after editing markdown file

[Ram042]

Describe the bug

Directory becomes undeletable after editing markdown files with built in basic markdown editor.

Same when moving directory - it becomes empty and cannot be deleted.

To Reproduce

1. sudo docker run --rm -p 3923:3923 docker.io/copyparty/ac -v /w::rwmda
2. create folder
3. create markdown file, edit, save
4. Try to delete directory

Server details

• server OS / version: v1.16.5 ac from docker

[9001]

thanks; I can confirm this is a bug, and I'll get it fixed for the next ver.

I believe this is happening because your user does not have permission to see dotfiles (hidden files/folders), so a quick workaround is to grant yourself that permission. The permission for this is . so if you already have rwmd then changing it to either rwmd. or A will avoid this issue (the A permission is an alias of rwmda.).

as for why this is necessary; the markdown editor takes a backup every time you save the document, and the backups are written to a folder next to the document named .hist. The bug is that you're not allowed to delete a folder that contains dotfiles, since the delete routine doesn't see the dotfiles.

While that itself is a simple and obvious fix, it opens a few questions. Currently, the same behavior applies to moves, renames, and copies. So if you rename or copy a folder without permission to see dotfiles, then those will not make it into the new destination. Intuitively this is probably also to be considered a bug -- if you rename, move, or copy a folder, then all of its contents should follow along. But the concern is that a user could perhaps move a folder into another volume where the user does have permission to see dotfiles, and thus become able to browse previously invisible files.

Relying on dotfiles to hide certain files/folders from view has always been discouraged in favor of using volumes, but I'll think about this some more before making the change.

EDIT: I think it is safe to make this change for renames and moves, since both of these operations require the user to have the m (move) permission in the source volume, which implies a certain level of trust. But I'm not sure what to do about copying. Maybe it's best to keep the current behavior in the specific case of a user copying a folder into a volume where dotfiles are visible, from a source volume where they aren't, and then otherwise include all dotfiles.