Delete file from catalog AND harddisk (network)

thomas olbrich

• 2011年07月14日 10:17

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. 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. 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.

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.
viewtopic.php?f=43&t=10590&start=0&st=0&sk=t&sd=a&hilit=network

This issue exists since iView Media Pro and MS Expression Media, too. A report to MS community in 2009 was answered with "this is a long standing limitation. (...) It is something we would love to fix in the future". Some weeks later this issue got classified as "solved" on the MS connect website. – Though it still occures today in Media Pro 1.0.1 ...

Media Pro 1.0.1 (also: former MS Expression Media, iView MediaPro)
Mac OSX 10.6.x (client + server)

Any hints to avoid this occurrence of undeletable files on a network volume via MediaPro is appreciated! Thanks, - thomas

(2011-07-15: typing error in last line corrected: 'files', not 'flees')

0

• 

  Larry_S

  • 2011年07月16日 04:59

  Whoa! That's an old bug I forgot about. Pretty nasty considering there's no Undo in MP. I read your post and decided to draft an AppleScript to stand in as a workaround.
  
  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. You will see Finder errors, if they occur (dismiss them to continue script). If there are errors, those items in catalog are selected and all errors are dumped into a TextEdit file.
  
  What it doesn't do: Remove catalog items that haven't had their actual files deleted.
  
  Use at your own risk and test thoroughly on files that have been backed up first!
  
  Download script here'>, or copy/paste following code into AppleScript Editor and compile and Save As...
  
  
  Delete Original Files - incl Network.scpt
  tell application "Media Pro"
activate

if not (exists catalog 1) then
beep
display dialog "No Catalogs are Open!" buttons {"Cancel"} with icon caution
return
end if

set itemCount to (count every media item of front catalog)
if itemCount is 0 then
beep
display dialog "No Items in Catalog!" buttons {"Cancel"} with icon caution
return
end if

tell front catalog
set theSelection to selection
if theSelection is {} then
beep
display dialog "Nothing Selected!" buttons {"Cancel"} with icon caution
return
end if

set myChoice to button returned of (display dialog "Do you really want to DELETE or TRASH the selected files?" & return & return & ¬
"Network-referenced files will be deleted, local files moved to Trash, and catalog items removed." buttons {"Cancel", "OK"} cancel button 1 default button 2 with icon caution)

if myChoice is "Cancel" then return


set problMess to {}
set probItems to {}

repeat with mediaItem in theSelection

select mediaItem

set fileMacPath to path of mediaItem
set fileName to name of mediaItem

if (mounted of mediaItem) then -- can't delete what's not there

tell application "Finder"
activate
set fileRef to (a reference to file fileMacPath)

(* Delete file via Finder, which should have authenticated already against file's server via AFP.
Works up to the permissions of user who logged into remote server, and local permissions. *)
try
if not (locked of fileRef) then
delete fileRef

tell application "Media Pro"
delete mediaItem
end tell
else
set the end of problMess to fileMacPath & ": File locked"
set the end of probItems to mediaItem
end if
on error errMsg number errNum
set the end of problMess to fileMacPath & ": Finder Error#" & errNum & " - " & errMsg
set the end of probItems to mediaItem
end try

end tell

else

set the end of problMess to fileMacPath & ": Volume not mounted or file missing"
set the end of probItems to mediaItem

end if

end repeat

activate
if probItems ≠ {} then

select probItems

set the beginning of problMess to "The following files had errors during attempted deletion..." & return & ¬
"They are selected in catalog."

set oldDelims to AppleScript's text item delimiters
set AppleScript's text item delimiters to {return & return}
set problMessTxt to problMess as string
set AppleScript's text item delimiters to oldDelims

tell application "TextEdit"
activate
set newDoc to make new document at beginning with properties {name:"Problem Files", text:problMessTxt}

beep 3

end tell

end if

end tell
end tell
  
  Thomas, you should consider submitting the bug via

  0
• 

  Robert Edwards

  • 2011年07月16日 23:33

  Hi Larry,
  
  Thanks for the script! I used to add items to a 'DELETE' Set then use 'Show items in Finder' to remove them from the server.
  
  This is a painful bug since more photographers are using servers.
  
  -- Robert.

  0
• 

  thomas olbrich

  • 2011年07月18日 07:46

  > Thomas, you should consider submitting the bug via http://www.phaseone.com/en/SupportMain/ ... pport.aspx.
  
  Yes, a case got opened (with any hardware and '12345' as serial no.) last week and confirmed same day. - I'll let the forum know if answers drop in.
  
  @ Larry, the Delete script does the trick as a charming workaround. - Thank you!
  I wonder how you managed the MP access rights issue: the script seems not to even touch this subject. As if the error in MP.app is a bug almost done in purpose ...
  
  - thomas

  0
• 

  Larry_S

  • 2011年07月18日 18:37

  [quote="thomas olbrich" wrote:
  > @ Larry, the Delete script does the trick as a charming workaround. - Thank you!
  I wonder how you managed the MP access rights issue: the script seems not to even touch this subject. 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. finding the file via the Finder. It just does it prior to deleting the catalog media item.
  
  From the comments in the script"
  
  

  Delete file via Finder, which should have authenticated already against file's server via AFP.
  Works up to the permissions of user who logged into remote server, and local permissions.

  
  
  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. read/write, etc.) as per the Sharing Preferences setup for the share/user on the server. 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. Maybe MP uses some old library that performs the delete without pre-authentication (which would of course fail).
  
  But wait, there's more... Using MP you can create new subfolders in the directory where you can't delete files (i.e. 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.
  
  I really don't see why this delete function should fail, when I can code the Finder to do it in 10 minutes. It certainly isn't a "long standing limitation," as Microsoft support indicated.
  
  Larry

  0
• 

  thomas olbrich

  • 2011年07月19日 14:29

  Thank you, Larry, for your hints and explanations.
  
  Meanhwile the case was responsed by the PhaseOne Support:
  "There are many permissions limitations when working over a server. Currently we cannot account for all of them but share your concern and are working towards correcting this in the future." – The case status got set to "5. Finished".
  
  Unfortunately it reminds me to the case at Microsoft Connect from January 2009, "FeedbackID=388713" which ended up with "Field Status changed from [Resolved] to [Closed]" just two weeks later. Hm.
  
  However, I forwarded the URL of Larrys recent post plus his useful script to the PhaseOne Support.
  
  So, let's hope together,
  With thanks in advance to PhaseOne Support,
  - thomas

  0
• 

  Larry_S

  • 2011年07月19日 16:38

  Thomas, thanks for the update on the bug report.
  
  One way to deal with the permission issue, on an app level, is with shared keys. 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.
  
  An elegant example of this setup is newer versions of Carbon Copy Cloner . It generates a small, simple Mac installer for setting up keys on both Macs. 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. Such a setup would be super-handy for admin who have very specific POSIX permissions and ACLs set up on shares on remote Macs.
  
  
  Tested Alternate Solution
  
  I get around all of this now by working on a master local drive and then synchronizing that drive to the remote Mac; then a shell script on that remote Mac (the file server) runs via 'sudo' and fixes all of the permissions on all of the shares at a set hourly interval and just after a synch. This setup gives me an admin-editable master and a network backup that also serves as the actual file server for our workgroup. Also, it keeps me from editing the workgroup server while others are using it, since synchronizations are done at night.
  
  My MP (EM 2) network share setup:
  
  1) Two admins edit the master drive(s) via MP (EM 2) and Finder (a la script). Put away photos from network workgroup drop box. Wholesale changes can be made, DNGs reworked, Photoshop working docs added, etc.
  
  2) Synchronize Pro X is used to run a shell script fixing permissions on master, then synching it to remote Mac share, which also pulls down to master any new workgroup drop box additions. Then lastly Synch Pro runs a clean up script that once again fixes permissions on both Macs (remote via SSH), and converts workgroup-dropped RAW files to DNG and backs them up (Python script). Then, triggers an AppleScript to import all new files, so the admins have fresh MP (EM 2) catalogs to work with in the morning.
  
  3) On next synch, all re-worked, converted DNGs replace the dropped RAW files and the workgroup gets fresh catalogs that only reference the newly minted DNGs.
  
  4) Synch Pro is also used to back up the master drive to an offsite storage facility on a rotating daily schedule.
  
  This setup has run, more or less, flawlessly for over 5 years, completely sidestepping the MP (EM 2) network permission issues. If interested, let me know if you would like copies of the permission fix shell scripts and a how-to on setting up remote, scripted sudo.
  
  Larry

  0
• 

  thomas olbrich

  • 2011年07月20日 08:25

  Larry, thank you for your detailed infos and your offer to share the files. Your solution sounds quite thought out and complex with its combination of Shell-, Python- and AppleScripts for both synchronizing and converting files automatically.
  
  Honestly said it exceeds my understanding, also your network sounds to be smaller and less complex than the one used here: 10 Mac clients (read & write), 5 Windows clients (read only) and a Mac server (hard & software server) plus hd raids (for files/ for backups). Aditionally this Mac network is embedded in a Windows network (approx. 80 clients, several servers), including the MS mail server and user directory. The Macs get backuped daily with Retrospect, the Mac users and user rights are administered via LDAP/Open Directory/Workgroup Manager, means they can't individually get set via the finders Info window and there seems to be no individual file owner for instance ...
  
  Years ago, when our Macs were less, the network smaller and the OS X older, the Mac users were sotosay 'single'/'simple' and also visible in the Mac files Info window. Additionally each single Mac client worked as file server, too. This method used to be error-prone occasionally for some files' user rights, we never realized why and why only those files. At that time a script solution was temporarily in use to repair the Mac user rights regularely. But this method didn't run failure free, rights seemed to get corrupted, any manual adjustment of user rights via the finders Info window made it either more badly or didn't do anything. That's why it was changed to the solution described above ... which nowadays works like a charm.
  
  Whereby I use at home Synchronize Pro to backup one Mac with one hd, additionally to Time Machine (compressed) for particular files/folders (uncompressed). –– At this point I am wondering why you need to adjust user rights after copying or get user right issues at your network, since, as far I remember, you may set the way user rights get treated while copying and when initializing your hd, too. I might be wrong but I also have in mind that CCC isn't such important as it used to be before OS X 10.6.x (snow leo) ... just my 2c.
  
  Finally, to me it remains weird that MP/EM2 is the only application which has issues with user rights concerning file deletion only (– compared to the bit more complex shared network use of a catalog, which does not run MP/EM2 into such issues).
  
  - thomas

  0

投稿コメントは受け付けていません。