Plik *.app i bezrozszerzenia w os x

Cześć ponownie,
Od 4 dni ślęczę nad modułem aktualizacji automatycznej do mojego programu bo nie mogę rozwiązać problemu.
W Windows wszystko gra super.
Natomiast coś dziwnego dzieje się podczas kopiowania na ftp i pobierania plików w OS X.
Aplikacja po stwierdzeniu istnienia na ftp nowej wersji , ściąga kolejno pliki w tym plik bez rozszerzenia wykonywalny systemu OS X( w windowsie robi to samo z exe i zamienia później nazwy.- tu działa bez zarzutu).
Natomiast w OS X po ściągnięciu pliku mimo takiego samego rozmiaru plikiem wykonywalnym już nie jest.
Nie rozumiem chyba budowy programów wykonywalnych w OS X. Czy ktoś może mi pomóc?
Po kompilacji lazarusem powstają dwa pliki jeden *.app i drugi bez rozszerzenia wykonywalny. Jeśli kliknie się wykonywalny to program uruchomi się z poziomu terminala. Natomiast kliknięcie w *.app uruchomi program tak jak w Windows bez uwięzionego okna w terminalu.
Programy uruchamiają się za pomocą tprocess i wszystko tu działa. Ale nie rozumiem tej utraty wykonywalności.... pliku podczas ściągania za pomocą ftpsend... synapse. Wszystkie inne pliki ściągane są dobrze. Próbowałem przed wysłaniem na serwer dodawać rozszerzenie *.mac tylko po to by plik nie był traktowany jak katalog przez serwer ftp i ściągać na dysk również jako *.mac ale przy rename tak samo jak przy bezpośrednim ściąganiu w domyślnej nazwie czyli bez rozszerzenia efekt jest ten sam. Plik przestaje być wykonywalny.

Pewnie nie ustawiasz poprawnych chmodów.

Co to znaczy?
To jakiś tryb bezpieczeństwa w systemie OS X ?
Jak to ustawić z poziomu mojego programu?
Mówisz o tym że system zabrania uruchamiania plików ściąganych z internetu?

a nie jest tak, że Maki mają domyślnie zablokowane odpalanie .app poza AppStore i trzeba zmienić w ustawieniach?

(o ile faktycznie taka jest tego przyczyna).

. Natomiast kliknięcie w .app uruchomi program tak jak w Windows bez uwięzionego okna w terminalu.
chociaż w sumie wtedy w ogóle by się nie uruchamiało, więc pewnie nie trafiłem z odpowiedzią.

No chyba to nie te chmod jednak.
I tez nie to ze nie Apple store... bo przecież kopiować w systemie za pomocą „myszki” mogę bez problemu na różne maki i wszędzie się program odpala.
Plik w informacji o sobie ma napisane ze jest textedit- rodzaj.
Załączyłem zdjęcie info o pliku i drugie zdjęcie katalogów w OS X w tym tego nieszczęsnego aktualizatormemo , który staje się nie czarnym exec jak obok Memo.... jak sciagnalbym Memo z ftp tez stałby się rodzaj - dokument textedit...

Używam lazarus 1.6.4, fpc 3.0.2

I ciekawostka jest taka ,że te same pliki wykonywalne systemu OS X ściągnięte przez wersje windowsowską tego programu są nadal plikami wykonywalnymi gdy widziane są na bootcampie z OS X . natomiast ściągnięte przez ten sam program tylko skompilowany na Mac OS X tracą atrybut wykonywalności ....

Windowbee napisał(a):

Używam lazarus 1.6.4, fpc 3.0.2

No to po pierwsze, taguj wątki nazwami języków/technologii, bo tego nie robisz. A po drugie – bieżącą wersją Lazarusa jest wersja 1.8.0 (a FPC to 3.0.4), więc najpierw zaktualizuj środowisko, przebuduj projekt i sprawdź jak to wygląda.

Nie rozumiem chyba budowy programów wykonywalnych w OS X. Czy ktoś może mi pomóc?
Po kompilacji lazarusem powstają dwa pliki jeden .app i drugi bez rozszerzenia wykonywalny

Ale .app to w rzeczywistości cały katalog, który OSX traktuje jak aplikację. W tym katalogu są rózne podkatalogi, i pliki konfiguracyjne, w których można ustalić parametry aplikacji (np. Info.plist).

https://en.wikipedia.org/wiki/Bundle_(macOS)#macOS_application_bundles
https://developer.apple.com/library/content/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html#//apple_ref/doc/uid/10000123i-CH101-SW1

Może więc tutaj nie budujesz poprawnego bundle'a makowego? Albo po prostu domyślnie odpala się bundle z okienka a nie w terminalu? (tak tylko zgaduję).

Jestem po reinstalacji do fpc 3.0.4
I lazarusa 1.8.0 i dalej to samo.
Myślałem ze coś z bundle zle jest ale jak czytam o tym to ja tam nic kompletnie nie zmieniam. Parametry są te same i plik wykonywalny tez jest ten sam zresztą pliku .app w ogóle nie ruszam. wędruje tylko na serwer ftp plik wykonywalny i wraca w to samo miejsce na dysku ale już nie jest wtedy traktowany jako wykonywalny. Ma po powrocie 8704732 B, a przed wysłaniem: 8704732B czyli powinien być tym samym plikiem :/

@Windowbee: czy masz zaznaczony checkbox Use Application Bundle for running and debugging w oknie ustawień projektu? Bo jeśli tak to go odznacz, przebuduj projekt i spróbuj w ten sposób.

Nie znam się kompletnie na systemach z jabłkiem i nigdy niczego pod te systemy nie robiłem, jednak sama treść tej opcji oznajmia, że ten bundle jest potrzebny do uruchamiania i debugowania, a jeśli go nie będzie to programu nie da się ani otworzyć, ani tym bardziej debugować.

Tak więc odznacz tę opcję, przebuduj i sprawdź czy działa. Jeśli działa to przenieś plik wykonywalny w inne miejsce na swoim dysku i znów sprawdź czy działa. Jeśli wszystko będzie grało to możesz śmiało wrzucić go na serwer.

Edit: zobacz też do tego artykułu – http://wiki.freepascal.org/Multiplatform_Programming_Guide#OS_X

Już chyba wiem co jest grane...
OS X zmienia pliki wykonywalne ładowane z internetu aby się nie mogły otworzyć..
Chyba zrobię jeszcze taki myk , ze zetnę nagłówek 1kb z początku pliku przed wysyłka , i dokleje go na koniec , po ściągnięciu pliku może wtedy system nie potraktuje takiego pliku jako zagrożenia.

Znów klęska w OS X.....
czy wiecie dlaczego plik wykonywalny systemu OS X po takiej zmianie 500 pierwszych bajtów i później ich odtworzeniu nie chce być już wykonywalnym?
Bo już ręce opadają :/ Chciałem jak w temacie głównym tego wątku zamienić bajty żeby system przy ściąganiu z ftp-a nie inaktywował execa. Ale Po tej operacji też staje sie nie aktywny... po uruchomieniu po sobie poniższych funkcji...oczywiście wszystko mogłoby być na rekordach i w jednej funkcji z jedą dodatkową zmienną boolean mówiącą czy przywracać czy zmieniać. Jednak chodzi o sam sposób

function zmiennaglowek(nazwa:string):boolean;
var
 x,y:integer;
 a:byte;
 f:file of byte;
begin
x:=1;y:=0;
assignfile(f,path+nazwa);
reset(f,1);

while x<500 do begin
seek(f,x);
read(f,a);
a:=a+50;
write(f,a);
x:=x+1;
end;
closefile(f);
end;
function przywrocnaglowek(nazwa:string):boolean;
var
 x,y:integer;
 a:byte;
 f:file of byte ;
begin
x:=1;y:=0;
assignfile(f,path+nazwa);
reset(f,1);

while x<500 do begin
seek(f,x);
read(f,a);
a:=a-50;
write(f,a);
x:=x+1;
end;
closefile(f);
end;

No jest identyczny... o ile te dwie moje funkcje działają. Ale wydaje mi się ze po wykonaniu po sobie dają identyczny plik z pierwotnym

Windowbee napisał(a):

No jest identyczny... o ile te dwie moje funkcje działają.

Bardzo pomocne są Twoje odpowiedzi.

Ale wydaje mi się ze po wykonaniu po sobie dają identyczny plik z pierwotnym

Nie wygłupiaj się i sprawdź czy te funkcje faktycznie działają… Do porównania zawartości dwóch plików wykorzystaj np. jakiś hex-edytor.

@furious programming
Masz racje.... pliki nie są identyczne , dołożyłem jeszcze raz seek(f,x) żeby znów ustawić miejsce operacji w pliku i zamiast dodawania zrobiłem xor. No i efekt jest taki ,że na dysku funkcje zaczęły działać. Plik uszkodzony celowo przez xor nie działa ale po ponownym wykonaniu odwrotnego xor znów działa jak oryginał.
Jednak poza tym okazuje się że to nie rozwiązuje problemu, głównego. Tzn że plik ściągany z serwera ftp jest innym plikiem niż ten na niego wysyłany. Powraca jako inny rodzaj pliku, nie rozumiem tego zupełnie. Wina serwera - chyba nie?(w Windows przychodzą pliki identyczne). Może dłuższy odcinek niż 500 bajtów powiniennem xorowac albo liczba przez którą wykonuje xor powinna pochodzić od pliku innego typu np dużej bitmapy? Mało dokumentacji znalazłem w internecie odnośnie tego problemu. Cały czas tylko gdybam. :/ z programowaniem zawodowym nic wspólnego nie mam jestem samoukiem a programy dość proste robię dla siebie tylko ew. Jeden zrobiłem dla swojego oddziału.

Jednak ... nie

Windowbee napisał(a):

Masz racje.... pliki nie są identyczne , dołożyłem jeszcze raz seek(f,x) żeby znów ustawić miejsce operacji w pliku i zamiast dodawania zrobiłem xor.

Użyj klasy TFileStream i zrób co masz zrobić w przyzwoity (wygodny) sposób. O jaki xor chodzi? Po co to?

No i efekt jest taki ,że na dysku funkcje zaczęły działać. Plik uszkodzony celowo przez xor nie działa ale po ponownym wykonaniu odwrotnego xor znów działa jak oryginał.

Już wiem po co (chyba). No tak działa xor – jest odwracalny.

Jednak poza tym okazuje się że to nie rozwiązuje problemu, głównego. Tzn że plik ściągany z serwera ftp jest innym plikiem niż ten na niego wysyłany. Powraca jako inny rodzaj pliku, nie rozumiem tego zupełnie.

Spróbuj dostarczać ten bundle razem z plikiem wykonywalnym.

Wina serwera - chyba nie?(w Windows przychodzą pliki identyczne).

Na pewno nie – jeśli plik został pobrany z serwera bezbłędnie to jest dokładnie tym, czym ma być.

Serio, pliki które wysyła mój program na serwer w Windows , są takie same jak te pobrane( również wykonywalne systemu OS X)
Natomiast program uruchomiony w OS X Sprawia ze pliki wykonywalne systemu os x po powrocie są innego typu. Ale dotyczy to tylko wykonywalnych systemu OS X.
Sprawa wyglada tak jakby OS X blokował i „unieszkodliwial” pliki wykonywalne OS X pobierane z internetu. Katalog .app czyli bundle nie ma nic do rzeczy nie zmienia się. Plik wykonywalny bez bundle tez wystartuje po kliknieciu ale wtedy w terminalu z bundle niezależnie.

Nic więcej nie jestem w stanie doradzić, a szkoda czasu na zgadywanie. Przejdź się na forum Free Pascala, zarejestruj się i tam zapytaj – chłopaki na pewno będą wiedzieć co robić (o ile przedstawisz problem w zrozumiały sposób).

@furious programming:
Dziękuje tak czy inaczej :) , za odpowiedzi.
Z jakiegoś powodu nie mogę otworzyć forum ani na komputerze ani na telefonie. Miałem tez problem żeby pobrać 1.8.0 lazarusa bo ich strona nie otwiera mi się.
Jak tylko ruszy to odwiedzę tamto forum być może będą wiedzieć o co chodzi.
Na ten moment w skrócie w OS X ( i postaram się jasno choć ze mną o to trudno...):

Jaki kolwiek plik wykonywalny otwarty przeze mnie do zapisu, - jeśli zmodyfikuję coś ,przestaje być automatycznie wykonywalnym. Nawet jeśli przywrócę oryginalne wcześniejsze bajty. I nie ważne czy odbywa się to z poziomu zapisu pliku pobieranego z internetu czy tez z poziomu dyskowych reset, write itp... efekt ten sam plik się nie chce wykonywać.
Swoje funkcje sprawdziłem oczywiście w tym samym programie w windowsie. Tam pliki systemu OS X po modyfikacjach np wysyłce na ftp i po powrocie , przy operacjach na plikach na dysku lokalnym nadal są wykonywalnymi plikami w systemie OS X.
Dlatego wydaje mi się że system OS X nie pozwala za bardzo na majstrowanie przy plikach wykonywalnych , ale musi istnieć jakiś sposób na to bo instalatory przecież zapisują i modyfikują pliki wykonywalne w systemie OS X. Kopiując „myszką” tez to robię.

Myślę, że to jest słuszne zabezpieczenie. Wirusy mogłyby modyfikować pliki wykonywalne, tak jak jest pod Windowsem. Na MacOS taki zmodyfikowany plik przestaje być wykonywalny, co od razu neutralizuje zagrożenie.

Na ten moment niestety , aby nie przedłużać tworzenia mojej aplikacji dałem w niej komunikat ze w celu aktualizacji należy uruchomić program w systemie Windows.( w Windows aktualizacja jest całkiem automatyczna) Jako ze jest bezinstalacyjny i działa na swoim katalogu , a przewidziany jest do pracy na pendrive to dużego kłopotu to nie sprawi użytkownikom OS X a będę mógł dalej pracować.
Może z czasem rozwiązanie się pojawi. :)

Po długiej przerwie , przy kolejnym programie problem rozwiązany:

W sekcji uses należy dodać:
(Dzięki temu kompilator bedzie wiedzial zeby to zrobić tylko w systemie unixowym)

USES
{$ifdef unix}
Unix,baseunix;
{$endif}

Var
Filepath: string;

Następnie w procedurze kopiującej lub tworzącej plik exec systemu os x już po przekopiownaiu lub zapisaniu pliku należy dodać znowu:

{$ifdef unix}
fpChmod (Filepath,&777); // filepath - scieżka do pliku ,który chcemy zrobić wykonywalnym.
{$endif}

I dzięki temu cały problem rozwiązany po paru latach. Plik ściągany z serwera po ściągnięciu potraktowany tym dodatkiem znów jest wykonywalny i to samo dotyczy kopiowanego pliku.