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). ----- Cheers, Sean -- View this message in context: http://forum.world.st/IMPORTANT-Issue-6351-FileReference-deleteAll-follows-s... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.