Hallo zusammen,
ich hoffe ich schreibe hier ins Richtigen Unterforum.
Folgendes: ich habe einen Pfad zu einer Datei und muss nun herausfinden, auf welcher gemounteten Platte diese Datei liegt liegt. Ich muss den MountDir wissen, da ich den Restilchen Speicherplatz berechnen will bevor ich in die Datei schreibe.
Beispiel
Dateiname: /var/opt/iserv.log
Folgendes ist gemountet:
/
/proc
/dev/fd
/var
/var/run
nun möchte ich mittels dem Dateinamen bzw. Pfad ("/var/opt/iserv.log") herausfinden, dass diese Datei auf "/var" liegt.
Wie kann ich mit C am besten/einfachsten/saubersten herausfinden, auf welchem gemounteten Verzeichnis die Datei liegt?
Danke für eure Bemühungen
lg jac
hi,
meine lm_sensors zeigen verdächtig viele ALARMs an und ich wollte mal eure meinung dazu hörn... mein netzteil hat nur 250W was wohl eindeutig zu wenig ist für die vorhandenne hardware... das system läuft seit tagen total stabil... können die spannungen welcher außerhalb der toleranz liegen meine hardware beschädigen? oder ist dies alles vielleicht schädlich für mein netzteil? danke schonmal für eure meinung
w83637hf-isa-0290
Adapter: ISA adapter
VCore: +1.51 V (min = +1.94 V, max = +1.94 V) ALARM
+12V: +12.34 V (min = +10.82 V, max = +13.19 V)
+3.3V: +3.44 V (min = +3.14 V, max = +3.47 V)
+5V: +5.07 V (min = +4.75 V, max = +5.25 V)
-12V: +6.06 V (min = -10.80 V, max = -13.18 V) ALARM
V5SB: +6.85 V (min = +4.76 V, max = +5.24 V) ALARM
VBat: +1.02 V (min = +2.40 V, max = +3.60 V) ALARM
fan1: 0 RPM (min = 5273 RPM, div = 8) ALARM
CPU Fan: 2410 RPM (min = 3515 RPM, div = 8) ALARM
fan3: 1163 RPM (min = -1 RPM, div = 8) ALARM
M/B Temp: +43°C (high = -128°C, hyst = -116°C) sensor = thermistor ALARM
CPU Temp: +41.0°C (high = +80°C, hyst = +75°C) sensor = thermistor
temp3: +43.0°C (high = +80°C, hyst = +75°C) sensor = thermistor
vid: +0.000 V (VRM Version 9.0)
alarms:
beep_enable:
Sound alarm enabled
mfg scat
Konkreter:
wie kann ich syslog() dazu bringen, mir in ein bestimmtes file zu loggen.
in der syslog-ng.conf.in (/etc/syslog-ng)
habe ich in destination natürlich file("/var/log/mist/nochmerhmist/"
hinzugefuegt.
rundem schrieb:
Jetzt versteh ich endlich warum einige Moderatoren hier als unfreundlich angesehen werden.
Ich werde den MIST gerne wo anders posten, wollte nur alte Threads nutzen um den MIST nicht nur neu aufzutischen...
Du hast den Mist schon woanders gepostet; sonst hätte ich nicht so reagiert.
Wenn Du eine Frage hast, dann stelle sie einmal, möglichst im passenden Forum. Zusätzlich noch andere Threads damit zuzumüllen, weil sie ein entfernt ähnliches Thema haben, ist nicht sinnvoll.
das Problem is, ich weiß nicht, wie mein Programm server child, welches den Kindprozess mit execl() überlagert den Client Socket nutzen kann.
Schritt (6) aus der Beschreibung zum inetd:
im neuen Child-Prozess nach fork():
close(1); /* close stdout */
fdout = dup(sockfd); /* stdout/fdout wird jetzt die Verbindung zum Socket WR */
close(0); /* close stdin */
fdin = dup(sockfd); /* stdin/fdin wird jetzt die Verbindung zum Socket RD */
Nach dem exec() kann man mit Ausgabe auf stdout (fdout==1) auf den socket schreiben, und von stdin (fdin==0) kann man lesen!
So in etwa macht es der inetd. Und funktioniert wunderbar auch woanders.
Wie es allerdings mit anderen Filedescriptoren funktioniert, könnte etwas problematischer werden. Ggf. alle anderen Filedescriptoren im Child zumachen (bis auf den sockfd) und dann die Filedescriptoren 3 und 4 nehmen. "Im Prinzip" werden die Filedescriptoren unverändert auch beim exec..() an das Child übergeben, es sei denn man benutzt FD_CLOEXEC (s.u.).
Das von Dir beschriebene Konzept ist zumindest für "normale" Server-Client-Kommunikation etwas unüblich. Normalerweise benutzt man eine Portnummer, um einen bestimmten Dienst zu definieren.
weitere Tipps:
Vorm exec() mittels fcntl() das Bit FD_CLOEXEC setzen für alle fd's die der child-Prozess nicht benötigt => befreit von unnötig belegten Filedescriptoren.
Reicht das erst einmal als Idee zur Verhinderung von unendlicher Anzahl der Ports? Sonst bitte weitere Fragen....
Wegen dem POSIX Standard gibt es vom Prinzip keine wirklichen Unterschiede, du koenntest aber vielleicht etwas Stoff finden wenn du die Art wie die Passwörter (auch Benutzernamen) gespeichert/gelesen werden (können) betrachtest.
Aber auch das koennen sich verschiedene Linux Distributionen untereinander mehr unterscheiden als "ein Linux" und "ein BSD".
Auch kann z.b. grsecurity u.a. Benutzer untereinander davon abhalten die Prozesse eines anderen zu "sehen".
Mit UML kannst du ein Kernel im Kernel starten. Mit posix ACL's kannste Zugriffsrechte präziser setzen.
Das fällt mir dazu so spontan ein.
Ja, hab ncurses auch gerad entdeckt, ich denke das sollte für meine Vorstellungen ganz brauchbar sein, jetzt erstma Bibliothek studieren...
Also, nochma vielen Dank!
Also hier wird diese ganze Problematik sehr ausführlich anhand von Beispielen beschrieben:
http://en.wikipedia.org/wiki/Name_decoration
(einen Deutschen Wiki Eintrag habe ich leider nicht gefunden, falls den jemand finden sollte dann nur her damit)
Und da ist deutlich erkennbar (siehe die Tabelle), daß man beim Versionssprung des GCC von 2.x auf 3.x sich an den Intel Compiler angepaßt hat.
Genaugenommen steht das sogar auch so da:
On IA-64, a standard ABI exists (see external links), which defines (among other things) a standard name-mangling scheme, and which is used by all the IA-64 compilers. GNU GCC 3.x, in addition, has adopted the name mangling scheme defined in this standard for use on other, non-Intel platforms.
Und von einer echten Standardisierung kann man leider auch nicht sprechen, oder spielt etwa Borland und Microsoft mit?
maximus schrieb:
Hi, ich bekomme den obigen Fehler bei folgendem code:
char* home= getenv("HOME");
file_= std::string(home) + std::string("/bla/" + counter + "conf.txt");
Wobei file_ eine Klassenvariable vom Typ std::string ist. Ich nehme mal an,
dass es mit home zusammenhaengt und ich den Speicher freigeben sollte. Weiss aber nicht so recht wie. Ein free(home) oder delete home funktioniert nicht.
std::string("/bla/" + counter + "conf.txt");
Denk mal kurz darüber nach, warum Du eigentlich den ganzen anderen Kram in Strings konvertierst...?!
Have phun
madmadmod schrieb:
Hallo
Ich schreibe hier in der Hoffnung, dass mit jemand helfen kann, bin echt am verzweifeln...
Ich versuche mit Hilfe von
#include <sys/stat.h>
#include <sys/types.h>
int mkdir(const char *pathname, mode_t mode);
verzeichnisse zu erstellen. Das funktioniert auch wunderbar, solange ich die Rechte (mode_t) hardcoded übergebe. Jedoch wird in meinem Programm dieser Wert als QString übergeben und ein casten in int lässt dann auch das führende 0 verschwinden. Ohne führendes 0 wird aber der Wert falsch intepretiert.
z.B. aus 0755 wird dann 755.
Strings werden natürlich als Parameter nicht akzeptiert.
Wenn jemand einen Tipp für mich hat, dann wäre ich echt dankbar!
Wie wäre es mit Handarbeit?
Lass das ganze überflüssige hin- und herkonvertieren sein und garantiere, dass der String immer nach "0755" aufgebaut ist (also "0" gefolgt von drei Zahlen von 0-7).
Da ich den QString nicht exakt kenne, nehme ich vorsichtshalber einen char *, die Verwendung ist vermutlich gleichwertig.
int StrToMode( char * string )
{
if( string[0] == '0' )
{
int result = 0;
for( int i = 1; i <= 3; i++ )
if( string[i] >= '0' && string[i] <= '7' )
result = result << 3 + string[i] - '0';
else return -1;
return result;
}
return -1;
}
Keine Ahnung, ob's funktioniert, ich habe es nur mal so daher getippert. Die ersten 4 Ziffern werden interpretiert, alles nachfolgende ignoriert. Sind die Ziffern nicht im gewünschten Format, wirft die Funktion -1 zurück. Solltest Du also was positives haben, sollte mkdir das schlucken.
have phun
Edit: Mit CodeFlags sieht's hübscher aus... :-\
Edit^2: Gna... aus i < 3 wird i <= 3 in der for-Bedingung.
Mal so auf die Schnelle:
Du darfst FD_SET() nur dort machen, wo du auch eine Eingabe erwartest. Wenn also der Client abgefertigt wurde, läßt Du ein einfach das FD_SET() für diesen fd weg. Im Prinzip gibt es auch noch eine Antwort auf diesem Kanal, wenn der Client den Kanal dichtgemacht hat (also beim EOF).
Die ganze Sequenz FD_ZERO, FD_SET sollte also in die while-Schleife rein!
Könnte das das Problem lösen?
hier eine Lösung:
http://www.cim.mcgill.ca/~franco/OpSys-304-427/messages/node71.html
oder auch hier unter 4.5
http://www.win.tue.nl/~aeb/linux/lk/lk-4.html
hab jetzt mal folgendes geändert:
socklen_t remoteAddrLen=sizeof(sockaddr_in);
rc=recvfrom(s,buf,256,0,(sockaddr*)&remoteAddr,/*sizeof(remoteAddr));//*/&remoteAddrLen);
da bekomm ich nun folgende meldung
client.cpp:97:3: Warnung: Kein Newline am Dateiende
/tmp/ccf93gCr.o(.text+0xad): In function main': : warning: thegets' function is dangerous and should not be used.
jemand ne idee?
gruß
ebrosius
edit: welche gets funktion?
edit2: ok, hab ne gets funktion drinne, welche aber nichts mit recvfrom zu tun hat. das wirds wohl sein. wollt den code sowieso in c++ umschreiben.
