IMPORTANT: Issue 6351: FileReference>>deleteAll follows symlinks in 1.4

This is a fun one to find out about by accident... Hey, what happened to my temporary variable names? Oh, they're decompiled because my image folder was deleted while deleting my home folder because the folder being deleted contained a symlink to it.

Thank god for backups... and that it was deleting alphabetically, so mostly rarely-changed config files were deleted (i think/hope)...

Pharo1.4
Latest update: #14448

'/path/to/dir' asFileReference deleteAll.
* If the link is valid, it follows it and keeps deleting
* If not, it claims the link file doesn't exist.

http://code.google.com/p/pharo/issues/detail?id=6351

Sean P. DeNigris wrote

* If the link is valid, it follows it and keeps deleting
http://code.google.com/p/pharo/issues/detail?id=6351

I think it would be more humane to remove this functionality completely until it works and is not dangerous, rather than leave it to explode on someone else. I was only alerted to it deleting my home directory because the image itself was there and caused an error. Luckily, I had everything backed up. Someone could get *really* screwed by this.

Sean P. DeNigris wrote

This is a fun one to find out about by accident... Hey, what happened to my temporary variable names? Oh, they're decompiled because my image folder was deleted while deleting my home folder because the folder being deleted contained a symlink to it.

Thank god for backups... and that it was deleting alphabetically, so mostly rarely-changed config files were deleted (i think/hope)...

'/path/to/dir' asFileReference deleteAll.
* If the link is valid, it follows it and keeps deleting
* If not, it claims the link file doesn't exist.

http://code.google.com/p/pharo/issues/detail?id=6351

Migrated to https://pharo.fogbugz.com/f/cases/7627

Fix in inbox: FileSystem-Core-SeanDeNigris.64
Please review.

Make DeleteVisitor check through the parents between the root of the deleteAll and each file to be deleted, and skips the deletion if any of them are symlinks, signaling a resumable error.

This is definitely inefficient, but...

I'm very uncomfortable leaving the current behavior.

I played around a bit, but I don't see a good way to handle this. #isSymlink makes it possible to identify symlinks (but not Mac aliases), and so not delete them, but I don't see a good hook in the deletion process.

To begin with, there doesn't seem to be a way to delete a link without deleting the pointed to file. Apparently lacking this VM support, the best we can do is skip symlinked directories

But besides that, DeleteVisitor relies on PostorderGuide to set up the traversal, and by the time it gets control back, the whole tree has already been pushed.

I thought about something like "PostorderGuide show: aReference to: self skipping: [ :e | ... ]." (i.e. adding #skipping:, but wasn't sure if it was generally useful enough to justify).