Currently Being ModeratedDec 7, 2011 12:33 PM (in response to jinniferb)
The closest thing I could find was this:
But none of the EHDs are formatted with NTFS, as the author indicated in the article as being the problem. All of our EHDs are formatted as Mac OS Extended (Journaled).
Also, it should be worth nothing that the check box for each drive's info pane is set to "Ignore this volume's ownership" if that makes any difference.
Currently Being ModeratedDec 7, 2011 3:09 PM (in response to jinniferb)
Get a third and preferably known-good external disk involved in the sequencing as the source or the target, and process your files normally.
If the problem persists with the new configuration, swap the new disk over to the other original disk, and process your files normally.
This to determine if you have a hardware error with one of the disks.
If the disks are bus powered, move to a powered hub, or (if the disks permit it) to an external power supply.
This to determine if your disks need more power than is available via the USB.
Currently Being ModeratedDec 8, 2011 9:29 AM (in response to MrHoffman)
The 8084 error is related to a power management issue?
One of the drives (data source) has its own dedicated power source, while the other drive (the one that the data is being copied to) runs off of USB power from the server.
So, I would need the second drive to have its own power source?
Currently Being ModeratedDec 8, 2011 9:20 PM (in response to jinniferb)
This is a guess and an attempt to reduce the scope of the problem and particularly an attempt to localize the error trigger for an error code that isn't particularly documented (beyond "the operation can’t be completed because an unexpected error occurred (error code -8084)" text), and some of the common triggers for flaky USB device errors can be due to power issues (too much draw or too little available power) and can include device errors. There can be other potential triggers for device errors, but these are among the easiest to test.
Currently Being ModeratedSep 11, 2012 1:55 PM (in response to jinniferb)
My workaround probably doesn't address "jinniferb"'s problem, but it may help others to nail down a similar problem, for example as described in the article cited by "jinniferb" (http://www.techweb.com/news/231901757/the-mac-emperor-has-no-clothes.html).
Symptom: I encountered the intermittent "error code -8084" problem when copying a large set of media files from a hard disk on a computer running Windows 7 (Computer A) over my wired home network to my Mac's OS X Extended Journalled hard disk on Computer B. I first tried to copy by selecting and dragging a bunch of files from one Finder Window to another on Computer B: One Finder window showing the source files on Computer A (connected via SMB protocol), the other showing the destination folder on the local computer (Computer B). [Note: dragging files from one folder to another on the same computer will cause a move; here the 2 folders are on different computers, so it was a copy instead]. If a copy operation involved even moderately amount of data(like 50MB), it nearly failed with certainty at some time before all the files were copied. And the failure didn't have anything to do with the files -- I knew for sure because I could copy the file at which the copy operation failed on the next copy attempt. I have over 3000 files with total size over 100GB to copy over the network. The copy operation would take over 3 hours to finish even without interruption, so just incrementally copying by hand after each failure wouldn't work for me in practice.
Workaround: It just so happened that Computer A was also a Mac, with the source data on the Bootcamp partition. So, I tried another tack: I booted Computer A into Mac OS X 10.6.8, same as Computer B. There was no problem opening a Finder window showing the source files in its Bootcomp partition. I opened another Finder window on Computer A with the destination folder on Computer B (but I don't which network protocol is being used in this case, probably not SMB). Now the copy worked without a hitch -- e.g. dragging over 100GB of files from one Finder Window completed after 3+ hours, without the mysterious "error code -8084".
So, at least in my case, the "error code -8084" is not caused by any of the following:
. an encrypted or unreadable source file.
. a problem with the hardware (disk, cable connections, power for hard drives etc) of the source computer or the destination computer.
. Time Machine -- computer B (the destination computer) has Time Machine running while the copy is going on.
. the parts of the network, that is unrelated to the computer operating systems or SMB protocol, which is used to network the 2 different operating systems.
. source files being on a NTFS disk and the destination on a hard disk formatted in OS X Extended Journaled.
The combination of NTFS Windows 7 talking to OS X over SMB seems to be cause of the instability.
Currently Being ModeratedDec 11, 2012 5:42 AM (in response to jinniferb)
For a file that is with or without a resource fork: when AppleFSCompression is applied, the compressed data may be stored in chunks in the resource fork.
In some situations a compressed file may become unopenable, in a way that can be neither recognised nor resolved by things such as Disk Utility.
Here with Mountain Lion, I have some files with AppleFSCompression that can be copied from one HFS Plus volume to another HFS Plus volume, no error is apparent and no decompression occurs.
If I attempt to copy or move the same files to a file system that is not HFS Plus: the action fails with error code -22 (a negative integer). In other situations for the same files, the error code is 22 (a positive integer).
Today I copied one of the files to a USB flash drive that uses JHFS+, then used that drive with Snow Leopard.
When I attempt to copy the compressed file from the flash drive to the desktop of the Snow Leopard user, the unexpected error is error code -8084.
So in my estimation, the likeliest cause in your case is a problem with AppleFSCompression, affecting some files.
Where some methods of copying will fail when an error such as -8084 or -22 occurs, you may find that ditto will succeed (the error will occur, but copying of other files may continue).
Currently Being ModeratedFeb 21, 2013 7:48 AM (in response to Graham Perrin)
Just worked this out. The problem is something in OSX, but you can use Terminal to get around it.
in your Utilities folder, open Terminal. This is a command-based operating system. Remember all these commands are case-sensitive.
Use the command df -h to display all your drives. They will be in a list that looks like /Volumes/A
Use the command ls or ls -a to display all files and folders in the folder you currently are.
Use the command cd to move around folders.
Eg cd .. to move to the parent folder.
eg cd Sub to move to the Sub folder in your current folder
eg cd "/Volumes/Public" to move to the top folder of your Public drive.
eg cd "/Volumes/A Folder with Spaces" where you have a folder name with spaces. Put the "" around the whole name.
Use the commands cp and mv (I prefer cp (ie copy) rather than mv (ie move) so I can go back and fix mistakes)
To copy a file from one drive to another, use the command:
cp filename destination don't worry about filetypes.
eg cp SNC* /Volumes/A to copy all files from your current folder starting with SNC to your A drive.
eg cp -r "/Volumes/Public/Book" /Volumes/A to copy your whole Book folder from your Public drive to your A drive. Remember the -r because this means copy the folder and everything in it.
Use this page http://ss64.com/osx/ for more help on the Terminal commands or use google search.
Also, use OSX to check that the files have moved etc. Leave your Terminal window open while you do.
Hope I'm not too cryptic. It's the middle of the night here.