Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I can read/write files within an NTFS external USB drive.

I have some problems with large files like AVI/MKV stored on an NTFS external drive. Those files appears greyed into Finder and, always using Finder, when I "Open With" my video player I receive a strange error:

Item “file.avi” is used by Mac OS X and cannot be opened.

Well, I found a workaround: if I drag & drop file.avi into my video player everything works fine.

But really I cannot figure out why this problem appears.

Please consider I haven't any NTFS custom drivers installed (i.e. MacFUSE or NTFS-3g). To mount my NTFS USB drive in R/W I have modified only /etc/fstab, adding the following line:

LABEL=WD320 none ntfs rw
share|improve this question
    
Is this only happening on media files (e.g. videos)? Can you specifically rule out some file types? –  slhck Jun 24 '11 at 11:03
    
Another thing you could try is to just install NTFS-3g and see if it works with that. –  slhck Jun 24 '11 at 11:11

4 Answers 4

up vote 5 down vote accepted

I've found a thread that deals with the very same subject. Files appear greyed out and can not be opened with the same error message.

Here are the steps to (hopefully) resolve it:

  • Download XCode 3 and install
  • Open a Terminal and run

    /Developer/Tools/GetFileInfo /Volumes/WD320/yourfile.avi
    
  • There should be information about the file type and creator and other file attributes

  • Now, change those attributes by calling

    /Developer/Tools/SetFile -c "" -t "" /Volumes/WD320/yourfile.avi
    
  • Now the file should play

I obviously couldn't try it (which I'd normally do), but maybe it helps.

share|improve this answer
    
Anybody care to explain why the downvote? @NSGod actually referred to my answer as the thing to try out -- his (very good) answer only explains the technical background though. –  slhck Jun 25 '11 at 17:08
1  
+1 Dunno why the downvote… –  NSGod Jun 25 '11 at 19:23
    
Very good. Thanks a lot for this suggestion :) –  freedev Jul 14 '11 at 18:35
    
Can you no longer edit these fields in the Finder file properties itself? They appear to be in editable text boxes in the screenshot given in the answer given by @NSGod. If you can, that would explain a downvote, if you recommended downloading an unnecessary program. –  trlkly May 24 at 16:43
    
@trikly: No, the window shown in my answer is a screenshot of Rainer Brockerhoff's Xray app (brockerhoff.net/xray). The Mac OS X Finder has never had the ability to edit file types and creator codes directly via a GUI (you may be able to use AppleScript). My intent with showing the image was to try to better illustrate what was happening. –  NSGod May 24 at 19:25

Item “file.avi” is used by Mac OS X and cannot be opened.

This means the item has had a file type of 'brok' and a creator code of 'MACS' set for it (and not cleared):

enter image description here

When you use the Finder to duplicate files, when the Finder first creates the duplicate file, it sets a special file type of 'brok', and a creator code of 'MACS' (the creator code of the Finder itself), to signify that the file is in use. Once the Finder finishes creating the duplicate file, it resets the file type and creator code to those of the original file.

Ordinarily, you'd only encounter a situation where the 'brok' file type isn't reset if the Finder were to crash or were somehow else interrupted during the file copy. If that isn't the case for you, then what you're seeing could well be a bug in the rw support of the built-in NTFS driver.

As slhck mentioned, you should be able to clear this reaction by the Finder by clearing the file type and creator code of the file-in-question.

share|improve this answer

My response to this problem is the result of cobbling together answers taken from several other posts (many thanks) and my own experience.

The background: I have an external hard drive with an NTFS file system. I want to plug it in occasionally. Previously the volume would mount 'read only'. Once I got that fixed, the files on the volume were in an unusable state. in order to get the volume mounted correctly and have the files accessible, I had to do the following:

FYI: I'm a kornshell user. Adjust these commands to your preferred shell.

sudo ksh

mv /sbin/mount_ntfs /sbin/mount_ntfs.orig

vi /sbin/mount_ntfs

#!/bin/ksh

# --- direct all script stdout to a temp file for examination
exec > /tmp/ntfs

# --- connect all stderr to stdout
exec 2>&1

# --- get the last argument on the command line - this is the mount point
eval echo \$$# |
read MOUNT_PT
echo "\${MOUNT_PT} = \"${MOUNT_PT}\""
echo

echo "Mounting $@"

# --- call the original ntfs mounter with the arguments handed in
/sbin/mount_ntfs.orig -o rw "$@"

echo "Mounted  $@"

# --- show the result of the mounting operation
mount

# --- fix files at the newly mounted MOUNT_PT that are in the 'brok' state
find "${MOUNT_PT}" -type f |
while read FILE; do

    # ---
    # --- use 'SetFile' to modify the file status
    # ---
    # --- this command line assumes the 'SetFile' command has been installed
    # --- and is available in your PATH
    # ---
    SetFile -c "" -t "" "${FILE}"

done

chmod a+x /sbin/mount_ntfs

chown root:wheel /sbin/mount_ntfs

Now, any time I plug in the disk, it is mounted 'read/write' and the files on the disk have their 'brok' status reset. This script works well for me. Your mileage may vary.

Enjoy --

share|improve this answer

Thanks a lot for this - I improved the script above as it didn't run on my OSX 10.8.4 machine (gave errors) and was a bit slow. Only need to check when an read-only disk is mounted... Changes marked with JCV CHANGED:

#!/bin/ksh

# --- direct all script stdout to a temp file for examination
exec > /tmp/ntfs

# --- connect all stderr to stdout
exec 2>&1

# --- get the last argument on the command line - this is the mount point
eval MOUNT_PT=\${$#}
# -- JCV CHANGED: corrected eval expression

echo "\${MOUNT_PT} = \"${MOUNT_PT}\""
echo

echo "Mounting $@"

# --- call the original ntfs mounter with the arguments handed in
/sbin/mount_ntfs.orig "$@"

echo "Mounted  $@"

# --- show the result of the mounting operation
 mount

# --- fix files at the newly mounted MOUNT_PT that are in the 'brok' state
find "${MOUNT_PT}" -type f |
while read FILE; do
  #JCV CHANGED: added check whether file type affected
  GetFileInfo -t "${FILE}"  | read FILETYPE
    if [[ $FILETYPE = "\"brok\"" ]];then
    # ---
    # --- use 'SetFile' to modify the file status
    # ---
    # --- this command line assumes the 'SetFile' command has been installed
    # --- and is available in your PATH
    # ---
    SetFile -c "" -t "" "${FILE}"
    echo "fixing file ${FILE}"
   fi
done
share|improve this answer
    
Could you please mention the changes made and why - thanks. –  suspectus Jul 28 '13 at 21:28
    
thanks for the reply - I tried to explain it in the post above. –  JCV Jul 29 '13 at 7:41
    
That means a reader has to read both code blocks and do a mental comparision. Some annotation to describe what you have done and why would be helpful. –  suspectus Jul 29 '13 at 7:44
1  
The script works only until the disk is remounted - then it has to change the parameters again. I tried changing setFile params to -c "????" (creator application unknown) which gives a persistent solution but then it confuses quicktime while opening a movie (unknown file type blah blag). –  JCV Jul 29 '13 at 17:44

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.