- #Applescript move files to trash without sound update#
- #Applescript move files to trash without sound full#
- #Applescript move files to trash without sound code#
- #Applescript move files to trash without sound mac#
#Applescript move files to trash without sound full#
Then, CCC uses the shared keys for remote access and can copy files with full 'sudo' privileges, which is even more than needed for most Media Pro operations.
#Applescript move files to trash without sound mac#
It generates a small, simple Mac installer for setting up keys on both Macs. With an admin account on the remote Mac and shared SSH keys between it and the accessing Mac (with the open catalog), full root access can be achieved, without enabling the root user on the remote Mac, without using any login passwords, and with full SSH 2 encryption.Īn elegant example of this setup is newer versions of Carbon Copy Cloner. One way to deal with the permission issue, on an app level, is with shared keys.
#Applescript move files to trash without sound update#
Thomas, thanks for the update on the bug report. It certainly isn't a "long standing limitation," as Microsoft support indicated.
#Applescript move files to trash without sound code#
I really don't see why this delete function should fail, when I can code the Finder to do it in 10 minutes. user having write permission is known by MP), but you can't subsequently delete the folder you created! What? So there is obviously some bug in MP's delete remote file function, because those directories and files I have tested do not have screwy custom ACLs, which would be the only way I can think of where you could have directories create-able, but not delete-able. Using MP you can create new subfolders in the directory where you can't delete files (i.e. Maybe MP uses some old library that performs the delete without pre-authentication (which would of course fail).īut wait, there's more. Why MP does not slave the the delete function of the Finder, which is authenticated against the remote server already, as I have done in the script, I do not know. read/write, etc.) as per the Sharing Preferences setup for the share/user on the server. Since you are logged into the remote file server (Mac with a file share-point) as a particular user, you have the permissions of that user in the Finder (e.g. Works up to the permissions of user who logged into remote server, and local permissions. It just does it prior to deleting the catalog media item.ĭelete file via Finder, which should have authenticated already against file's server via AFP. As if the error in MP.app is a bug almost done in purpose thomas: The script basically does what you were doing manually, i.e. I wonder how you managed the MP access rights issue: the script seems not to even touch this subject. > the Delete script does the trick as a charming workaround. Thomas, you should consider submitting the bug via Use at your own risk and test thoroughly on files that have been backed up first!ĭownload script here'>, or copy/paste following code into AppleScript Editor and compile and Save As.ĭelete Original Files - incl Network.scptĭisplay dialog "No Catalogs are Open!" buttons
What it doesn't do: Remove catalog items that haven't had their actual files deleted. If there are errors, those items in catalog are selected and all errors are dumped into a TextEdit file. You will see Finder errors, if they occur (dismiss them to continue script). What it does: 'Network-referenced files will be deleted, local files moved to Trash, and catalog items removed.' Activates and switches to Finder to do deleting. I read your post and decided to draft an AppleScript to stand in as a workaround.
Pretty nasty considering there's no Undo in MP. (: typing error in last line corrected: 'files', not 'flees') Media Pro 1.0.1 (also: former MS Expression Media, iView MediaPro)Īny hints to avoid this occurrence of undeletable files on a network volume via MediaPro is appreciated! Thanks, - thomas – Though it still occures today in Media Pro 1.0.1. Some weeks later this issue got classified as "solved" on the MS connect website. (.) It is something we would love to fix in the future". A report to MS community in 2009 was answered with "this is a long standing limitation. This issue exists since iView Media Pro and MS Expression Media, too. I did read the topic "Networking support?" but it seems to point on sharing catalogs via email or network in general, not to this catalogs functionality mentioned above. After this action it is quite harder to find/locate the file which should get deleted, one needs to search for it via the system GUI since the according entry in the catalog has gone already. This feature does not work for any file stored on a network/server volume: the element disappears from the catalog and pops up this message afterwards "Insufficient access privilegs" – whereas the file itself remains on the harddisk. There is an issue with catalog elements stored on a network/server volume: Usually if you delete a catalog element with command-delete-click its according file gets deleted from harddisk, too.