Other question:
Other question:
// TDirectory.Copy( QuelleExe, ZielExe );
TDirectory.Move( QuelleExe, ZielExe );
I try to copy a app to the applications folder.
If i use "Move" then the App is moved from the source directory to the applications folder. I can start it.
If i use "Copy" then the app is copied from the source directory to the applications folder. But then i can't start it from there. It feels like the app has forgotten that it is an app.
Do i miss something?
// TDirectory.Copy( QuelleExe, ZielExe );
TDirectory.Move( QuelleExe, ZielExe );
I try to copy a app to the applications folder.
If i use "Move" then the App is moved from the source directory to the applications folder. I can start it.
If i use "Copy" then the app is copied from the source directory to the applications folder. But then i can't start it from there. It feels like the app has forgotten that it is an app.
Do i miss something?
Which OS? Windows?
ReplyDeleteYou should raise this as a bug on Quality Portal - TDirectory.Copy hasn't maintained the executable's executable bit. To see this visually, in Finder, right click on the source bundle and choose 'Show Package Contents'; drill down to Contents/MacOS, and the executable (NB - doesn't have an extension) is shown with a black executable icon and a 'Kind' of 'Unix executable'. Do the same with the copied bundle, and the executable isn't shown like that.
ReplyDeleteIf you're going to work in OS X, you should spend some time familiarizing yourself with how the *nix file system differs from Windows. It's much richer, simpler, and is consistent across virtually all *nix platforms. Windows started out based on DOS, and DOS inherited a small fraction of the *nix design (mainly copied from CP/M), corrupted from the outset to support a smaller, slower environment. It has been "enhanced" over time to bring it closer to the *nix standard, but it's still not consistent with the simple and elegant design that was originally built into Unix.
ReplyDeleteIn *nix environments, directories are represented by something called INODEs, and they point to associated INODEs. It's like a big hierarchical linked list. A "move" literally moves the INODE in the file tree, so all of the permissions and associated INODEs beneath it are untouched. A "copy" creates a NEW INODE -- and it's a "shallow copy" by default. It also does not automatically inherit all of the permissions of the original INODE. There's a system setting that identifies the defaults that new INODEs are given when they're created, and it's fairly conservative for security purposes.
Take a look at all of the variations of the 'cp' shell command (type "man cp" in a command shell) and you'll get a feel for its richness. The 'cp' command reflects how the file system works.
Until you've grokked this stuff, you're going to be stumbling around the file system like a drunken sailor in a dark alley. It's much richer than Windows, and at the same time much simpler (IMHO).
Hmm, well in the spirit of a slight tipsy sailor...:
ReplyDeleteresourcestring
SInvalidBundlePath = 'Invalid bundle path';
procedure CopyBundleToApplicationsFolder(const SourceBundle: string);
var
Attr: TFileAttributes;
DestBundle: string;
SearchRec: TSearchRec;
begin
if not DirectoryExists(SourceBundle) or not SourceBundle.EndsWith('.app') then
raise EInOutError.CreateRes(@SInvalidBundlePath);
DestBundle := '/Applications/' + ExtractFileName(SourceBundle);
TDirectory.Copy(SourceBundle, DestBundle);
if FindFirst(SourceBundle + '/Contents/MacOS/*', faAnyFile and not faDirectory, SearchRec) = 0 then
try
repeat
Attr := TFile.GetAttributes(SourceBundle + '/Contents/MacOS/' + SearchRec.Name);
TFile.SetAttributes(DestBundle + '/Contents/MacOS/' + SearchRec.Name, Attr);
until FindNext(SearchRec) <> 0;
finally
FindClose(SearchRec);
end;
end;
Only Contents/MacOS/ needs to be fixed up.
David Schwartz it may be true that *nix file system APIs are richer, however the point of a cross platform RTL is surely to shield the programmer from platform differences, within reason - if the developer wishes to embrace the richness of a particular platform, they can call the native API directly. In fact, in the case of TDirectory.Move, System.IOUtils does actually do a form of attribute patching then restoring for Windows (albeit for a different purpose)... so I'd say TDirectory.Copy should do something similar for Posix.
ReplyDeleteJean-Marc Kiener - have a look and see if there's anything already on Quality Portal. If there isn't, I'd be happy to raise a report myself, as the issue is generic.
David Schwartz I don't really see how this is richer than Windows. Can you elaborate. What am I missing?
ReplyDeleteThomas Mueller OSX
ReplyDeleteChris Rolliston David Schwartz
ReplyDeleteThanks for the explanation/code.
In my case i was asked for a small installation program in windows/osx. Copy the app/setup.exe to the "program files" folder, write some configuration information to the users directory and execute it. In Winodws it was done in minutes because of course i got a lot experience on this platform.
It is my first time i have to "interact" with OSX, so yes, i underestimated the differences between the file systems.
In my opinion both of you are right. I should learn more about the unix file system and on the other hand for easy operations like copy a app there should be some wrapper in the fmx library.
Chris Rolliston
ReplyDeleteI did not found any equalent entry in quality portal. So feel free to report the issue.