Re: Direct networking and phantom volumes (Volume-1)
Re: Direct networking and phantom volumes (Volume-1)
- Subject: Re: Direct networking and phantom volumes (Volume-1)
- From: Philip Aker <email@hidden>
- Date: Wed, 23 Apr 2008 06:22:19 -0700
On 08-04-23, at 05:52, Loren Ryter wrote:
This is probably not the best forum for this question. If anyone has a better suggestion of where to ask this please let me know.
One of my applications uses direct networking to read a file on a remote machine. It mounts the remote user directory as a local volume, and reads the file:
/Volumes/RemoteUser/Path/File.txt
The problem I am seeing is that in some cases, the volume "RemoteUser" appears to be mounted as a phantom volume, so the path obtained is:
/Volumes/RemoteUser-1/Path/File.txt
My questions are:
1. what causes this and how can it be avoided? It seems to be more likely to happen on Leopard
2. how can this be worked around?
3. what to tell users to do if this happens? If this happened to me I would drop into terminal and RM the phantom volume "alias" file after restarting and making sure the volume was not actually mounted. I am as you will understand very reluctant to tell users to do this.
This is a known issue (search the archives). Like if you have an Xcode project open and yank out the FireWire disk it's on, Xcode will recreate a stub folder and directory hierarchy in /Volumesand save the project in there. So next time you mount the real volume, that numerical appendage will appear because HFS can handle duplicate disk names but unix can't.
The usual cause of the problem is of course hard-wired paths. So if you have hard-wired name for the volume, then you can use 'list disks' and scan the result for multiple items starting with with the same prefix, show an alert, and then open the folder for them to deal with it:
tell application "Finder" to open POSIX file "/Volumes"
There are other low level ways to lessen the chance this will occur (like a shutdown script for starters) but the above solution puts it in the hands of the user. A good choice I think because they might have been at least partially responsible for the problem…
Philip Aker
|
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden