I read here on the forum some times ago than we could use a Shell Asynchronous control to copy large file and keep application access (not is it was freezed).
Then instead of use:
MySourceFolderItem.CopyTo MyDestFolderItem
I use:
cp -a MySourceFolderItem.ShellPath MyDestFolderItem.ShellPath
as -a is -RpP and -p should preserve Creation date and Modification date of the source file. It is ok on local volume. But it does not work on mounted volume (NAS), the Creation date and Modification date are the actual date.
The problem is the same if I copy from the Terminal entering directly the cp command (that’s why I create this topic in Off-Topic as it is not Xojo the problem).
The problem is the same if I copy a file (not a folder) using the shell command cp -p .
I didn’t find someone speaking about this problem on te web.
Does someone has the same problem? I’m under Sonoma 14.6.1 (23G93).
It seems than
ditto MySourceFolderItem.ShellPath MyDestFolderItem.ShellPath
works.
I was just going to suggest ditto. It’s fully Mac aware (properly copies attributes, etc).
Thank you Eric, I try:
ditto --norsrc
and the file authorisation and the Creation and Modification date are copied. What is excluse with –norsrc ?
Ii is written in the man ditto:
Do not preserve resource forks and HFS meta-data. If both --norsrc and --rsrc are passed, whichever is passed last will take precedence. Both options override
DITTONORSRC. Unless explicitly specified, --norsrc also implies --noextattr and --noacl to match the behavior of Mac OS X 10.4.
but I don’t really understand what it means.
I ask because, for some file to copy on my NAS, I have to add –norsrc because if not I have an error “Operation not supported”.
The resource fork was a feature of Mac files starting all the way back to the original System 1 on the first Mac. A file would have two “forks”: the data fork (which is what essentially all files are today) and the resource fork, a collection of data stored in a structured fashion that could be accessed by the system and other programs. The idea is that data that was meant to be shared, like a file’s icon, could be stored in a standardized way so other programs could access it. In the original Mac system, the resource fork was used very extensively by the operating system and applications; in fact, applications were often nothing BUT a resource fork filled with executable code, icons, window definitions, localized strings, etc.
As far as the user is concerned, they only see a single file (not two forks) and so there is a seamless experience when moving the files around; there’s no way to accidentally leave behind one fork or the other. Mac bundles are the modern implementation of this very useful feature and owe a lot to the ideas driving the resource fork.
It was actually an incredibly innovative feature for the time, and it made the original Mac system performant and extensible. The downside is that as an incredibly innovative feature, it was of course completely unsupported on non-Mac file systems, which had no notion of a multi-fork file. Mac files with resource forks would be damaged if moved to and from such a file system, and there sprang up many file copy tools that would separate the resource fork when copying off the Mac and then reassemble the file when copying it back.
‘ditto’ has the option to drop the resource fork for this very reason: plenty of file system don’t support forked files and will throw errors if you try; or, they’ll create ‘my file.rsrc’ crud all over the place. Unless you are dealing with truly antique files, it should be very safe to use --norsrc.
Waouww, thank you very much Eric to take the time to explain me. The file which cause trouble has no ressource fork, but it has 2 Admin group. I don’t know why, may be I made a mistake changing permission:
the first Admin group can read and write, and the second can only read.
When I copy this file on my NAS with ditto I have the error “Operation not supported” and if I use ditto --norsrc it is copied. I have no problem if I copy it somewhere else on my local volume even if I use only ditto (without --norsrc ).
I added a checkbox in my application “No rsrc” in order to not copy ressources. This checkbox was False by default, then I should set it to True in default if I well understood your explanation (when the checkbox is checked, I use ditto --norsrc ). As the users of the last version of my application are supposed to use a recent system.
What kinds of files are being copied? Anything your app creates will not have a resource fork, they have been deprecated for … nearly 25 years? OS X never used them.
My application is a synchronisation software, it copy what is in the folder to sync. In this case, the file with strange permission is an X-Plane file. I copied many files from my old Mac under Mojave to my new Mac M3 under Sonoma.
If I copy with ditto an entire folder which has a custom icon, the copied folder keep the custom icon, but not if i use --norsrc . But I did only one test, it’s late now in France. Thanks again for your help.