Loading Profile...
The magical reappearing folder trick
I have come across a problem related to deleting directories. I'm connected via Expandrive to my home directory on a Solaris machine. When attempting to delete a directory by dragging the folder from the Expandrive window to the Trash, I get the usual server warning that the items will be deleted immediately.
On confirming this, the folder disappears. Only, a few moments later, to magically reappear - though without any files that were present when the folder was 'deleted'. I tried connecting to the server with a command line ssh window, and it appears from doing a bit of testing, that the .DS_Store file's presence or absence is what causes the folder to reappear or to stay deleted. Deleting it from the command line using rm and then deleting the problem folder works as expected, and the folder stays deleted when I drag it to the Trash. I'm using the latest build (1.27).
On confirming this, the folder disappears. Only, a few moments later, to magically reappear - though without any files that were present when the folder was 'deleted'. I tried connecting to the server with a command line ssh window, and it appears from doing a bit of testing, that the .DS_Store file's presence or absence is what causes the folder to reappear or to stay deleted. Deleting it from the command line using rm and then deleting the problem folder works as expected, and the folder stays deleted when I drag it to the Trash. I'm using the latest build (1.27).
I’m frustrated
1
person has this problem
I have this problem, too!
Tell me when someone solves it.
The more people who report this problem, the more it gets noticed.
The more people who report this problem, the more it gets noticed.
-
Inappropriate?This is a known, but rare problem. In order to trick Finder into correct behavior, we have to pretend some folders on server have .DS_Store files. This naturally means any .DS_Store files in that folder before ExpanDrive got to it are going to cause problems. We don't create any .DS_Stores with ExpanDrive, so you must have transferred a local folder using some other client (SSHFS perhaps?).
We have three options for proceeding. One, we could leave it as is. Most people are fine with this because it means no .DS_Store files are created on server, but Finder displays correct behavior with folder views and copying entire folders. If you for some reason have .DS_Stores present on server, you'll to manually remove them. Two, we could have ExpanDrive delete an .DS_Store files it encounters during a directory listing. We don't really like this because we don't want to get into the business of modifying files we didn't explicitly create, but it would work. Three, we could provide the option to not do anything. .DS_Store files would persist on the server, but that won't cause any problems in and of itself. What works the best for you?
1 person says
this solves the problem
-
Inappropriate?Thanks for the explanation. I'm not sure how the .DS_Store file arose - the folder I'm accessing was one I created a long time ago and have only just rediscovered. Thinking back it was probably mounted over AFP.
I think I'll manage with it as is for now. The work around - to delete the file manually over a standard SSH connection isn't too onerous. It could probably do with an entry in an FAQ or the program help files though. Thanks for an excellent little utility.
I’m happy
