Beiträge von misterspeed

Ändert nichts daran, dass du nachwievor nicht gepostet hast wie du die Datei und vorallem was für eine Datei du entpackst. Sollen wir raten? Je nach Methode schaut die Lösung anders aus. Selbst wenn sich die Struktur innerhalb der Zip Datei ändert kannst du immernoch Funktionen wie _filelisttoarray und co. verwenden um z.B. die Setup.exe zu finden, falls es sich überhaupt um ein Programmsetup handelt.

Zitat von Zattoo

ok aber ich kann damit nichts anfangen
ihr meint also einfach zurückgeben?
hätttet ihr da ne email? habe ja schon gepostet das die help seite von denen (bei mir) nicht geht
mfg

Also bei mir geht die Support Seite ebenfalls problemlos. (Firefox 17 + aktuelle Flash Version)
Übersichtlich ist zwar was anderes, aber was erwartet man schon von Gamer-Produkt Herstellern.

Hier eine allgemein gültige Emailadresse des Supports, welcher dir vermutlich auch nur vorgefertigte Antworten und Links zur Supportpage schicken wird, vielleicht hast du aber auch Glück und bekommst einen entscheidenden Tipp: support-us@razersupport.com (vermutlich wird englisch erwartet)

Schritt 1 sollte also sein deinen Browser in Ordnung zu bringen. Einen Firmware Download konnte ich aber btw auch keinen finden, lediglich den aktuellen Windowstreiber ( http://www.razersupport.com/index.php?_m=downloads&_a=view&parentcategoryid=111&pcid=20&nav=0,77,20 )

Garantie gewährt Razer auf Tastaturen anscheinend nur für 1 Jahr (tja braucht man sich wohl nicht fragen warum): http://www.razerzone.com/warranty
Da du in D grundsätzlich 2 Jahre Gewährleistung durch den Händler hast wäre wohl eine Reklamation dort noch am erfolgreichsten, sofern nicht zu alt.

Warum willste das machen? Da liegen höchstwahrscheinlich schon zig andere Dateien, was das Risiko erhöht, dass sich dort bereits eine gleichnamige Datei wie in deiner Zip-Datei befindet (z.b. setup.exe oder install.log usw.). Alleine deswegen macht es durchaus Sinn einen Unterordner zum entpacken zu nutzen. Ich sehe ehrlich gesagt auch keinerlei Nachteile wenn sich die entpackten Dateien in einem Unterverzeichnis befinden, sinnvollerweise natürlich ein selbstgewähltes damit du mit den entpackten Dateien weiterarbeiten kannst.

Da es gefühlte tausend Möglichkeiten gibt ZIP-Dateien zu entpacken (per Windows, 7zip, WinRaR...) solltest du aber wohl erstmal ein Testscript posten wenn du hier Hilfe erwartest.

Zitat

Ok, hab ich beim Scripten noch nie benötigt. Aber interessante Info... Welche Scriptsprache beherrscht das denn ?

- Python anscheinend: http://www.tutorialspoint.com/python/python_multithreading.htm
- Ruby meines Wissens nach ebenfalls
- Powershell ab Verison 2 scheinbar auch, siehe google.

Ein weiterer Vorteil von Python und z.B. auch Ruby wären im übrigen, dass sie auch unter Linux einsetzbar sind. Autoit ist leider auf Windows Umgebungen begrenzt.

Ein gravierender Nachteil von AutoIT wäre, dass es kein Multithreading unterstützt und dadurch je nach Aufgabe massive Geschwindigkeitsnachteile zu anderen Sprachen hat. Grundsätzlich kann man das aber durch den Einsatz multipler Instanzen oder durch seperate Teilprogramme umgehen. Ansonsten finde ich AutoIT eine schöne Script Sprache die man sehr schnell erlernen kann (was evtl. auch für neue Kollegen relevant sein kann).

Sich auf eine gemeinsame Sprache der eingesetzten Scripte festzulegen macht in jedem Fall Sinn. So kann auf lange Sicht jeder Verantwortliche Änderungen und Anpassungen an den Scripten vornehmen ohne dafür 5 Sprachen zu beherschen.

Zitat von mr_merlin

Habe das Skript von Oscar + bern670, welches mir ein Array mit allen Datein zurückgibt. Soweit so gut - nur weiß ich derzeit beim besten Willen nicht, wo ich die Fileprüfung auf 0 Byte einfügen kann.

Warum willst du was an dieser Funktion ändern? Benutz sie einfach und arbeite mit dem Ergebnis weiter.

$aAllFiles = _RecursiveFileListToArray(...)
for $i = 1 to ubound($aAllFiles)-1
if filegetsize($aAllFiles[$i]) = 0 then machwas($aAllFiles[$i])
next

func machwas($file)
; hier z.b. mit filewriteline die Datei in eine txt schreiben
endfunc

Dann hat dein Benutzeraccount keine Schreibrechte für die Datei oder die Datei hat das Attribut schreibgeschützt. Eine manuelle Änderung mit Notepad dürfte also ebenfalls scheitern, kannste ja mal ausprobieren. Sofern sich die Datei in einem Windows Verzeichnis wie "programme" oder "system32" befindet kann es auch sein dass die Benutzerkontensteuerung einen schreibenden Zugriff verweigert.

Funktioniert doch einwandfrei, aber hier mal noch eine Variante mit Debuging, so dass du anhand der Fehlercodes (siehe Hilfe) das Problem eingrenzen kannst.

#include <File.au3>
#include <array.au3>

Global $array[1]
$sFile = "C:\test\test.csv"
if Not FileExists($sFile) Then Exit MsgBox(0,"Fehler","Datei existiert nicht")

if _FileReadToArray($sFile, $array) = 0 Then
MsgBox(0,"Fehler beim einlesen der Datei","errorcode: " & @error)
Exit
Else
_ArrayDisplay($array,"unbearbeitetes Array")
EndIf

For $i = 1 To UBound($array) - 1
$array[$i] = StringReplace($array[$i], "&gt;", " ")
Next

_ArrayDisplay($array,"bearbeitetes Array")
if _FileWriteFromArray($sFile, $array, 1) = 0 Then MsgBox(0,"Fehler beim schreiben der Datei","errorcode: " & @error)

Das hier langt völlig:

$hDownload1 = InetRead("http://www.kitestuff.at/weather_station/Out.txt",1)
FileWrite($localfile1,StringReplace(BinaryToString($hDownload1),@LF,@CRLF))

Die Zeilenumbrüche werden serverseitig nur als @LF dargestellt (oder das @CR geht unterwegs verloren....), was unter Windows bzw im Notepad dann eben wie eine Zeile ausschaut.

Vermutlich in dem du diese Zeile auskommentierst...

ShellExecute($s_LocalFile)

Klicks auf Koordinaten sind ohnehin ziemlich unbrauchbar, da abhängig von der Bildschirmauflösung und ggf. der Fensterposition in dem der Klick ausgeführt werden soll. Schau dir besser mal die control*-Funktionen an:

controlclick
controlsend
controlcommand
controllistview

Da dein Beispiel grundsätzlich funktioniert wäre ein konkreteres Beispiel in Form deines kompletten Scriptes sinnvoll.

Würde auch mal vermuten, dass du bei einer gewissen Dateianzahl an die Grenzen der erlaubten Parameteranzahl kommst. Robocopy bietet aber anscheinend auch die Möglichkeit eine JOB-Datei abzuarbeiten. Dein Autoit Script könnte also eine solche Datei erzeugen und dann Robocopy für beide Jobs aufrufen.

http://www.skonet.com/Articles_Archi…b_Template.aspx

EDIT:

Zitat von autoBert

[autoit]

FileWrite

[/autoit]

Öhm ich denke mal er meinte wie er in einer Schleife den Parameterstring zusammenbaut...

$sCMDa = @WindowsDir & "\System32\robocopy " & $sourcepath & " " & "\\" & $ip_d2n2 & $targetpath
$sCMDb = $sCMDa

for $i=0 to ubound($FileList)-1
if $i > ubound($FileList)-1 then exitloop
$sCMDa &= " " & $FileList[$i]
$i += 1 ; damit nur jede zweite datei im String landet
if $i > ubound($FileList)-1 then exitloop
$sCMDb &= " " & $FileList[$i]
next

consolewrite($sCMDa & @crlf)
consolewrite($sCMDb & @crlf)

;Run($sCMDa, @WindowsDir, @SW_HIDE)
;Run($sCMDb, @WindowsDir, @SW_HIDE)

Zitat von minx

Wir hatten hier bereits mehrmals ausführlich über Ebay-Scripte diskutiert und sind zu dem Schluss gekommen, dass sie AGB-widrig sind.

Jetzt bin ich aber neugierig wer "wir" ist und wo diese Threads sein sollen, denn die Forensuche in Verbindung mit dem Suchbegriff "ebay" findet zu genüge Threads, in denen kein einziges Wort zu den Forenregeln verloren wird.

Zitat von AGB

§ 18 Systemintegrität und Störung der eBay-Website
1.
Mitglieder dürfen keine Mechanismen, Software oder sonstige Scripts in Verbindung mit der Nutzung der eBay-Website verwenden, die das Funktionieren der eBay-Website stören können.
2.
Mitglieder dürfen keine Maßnahmen ergreifen, die eine unzumutbare oder übermäßige Belastung der eBay-Infrastruktur zur Folge haben können.
3.
Mitglieder dürfen keine von eBay generierten Inhalte blockieren, überschreiben oder modifizieren oder in sonstiger Weise störend in die eBay-Website eingreifen.
4.
Die auf der eBay-Website abgelegten Inhalte dürfen ohne vorherige Zustimmung der Rechteinhaber weder kopiert oder verbreitet, noch in sonstiger Weise genutzt oder vervielfältigt werden. Dies gilt auch für ein Kopieren im Wege von "Robot/Crawler"-Suchmaschinentechnologien oder durch sonstige automatische Mechanismen.

Alles anzeigen

Zitat von minx

Man muss sich nicht künstlich irgendwelche Schlupflöcher basteln nur um so was zu rechtfertigen.

Also wirklich ich will dir ja nicht zu nahe treten, aber kannst du lesen und verstehst die AGB?

Hier ist ausdrücklich nur die Rede von der "Systemintegrität und Störung der Webseite". Alles was diese gefährdet ist nicht erlaubt. Dieser AGB Abschnitt befasst sich eindeutig nicht mit harmlosen Scripten die die Webseite in keiner Weise negativ beeinflussen.

Zeig mir ein Autoit Script dass Punkt 1 erfüllt, das schafft hier keiner so einfach und ist sicher auch nicht das Ziel des Threadstarters.
Punkt 2 ist ebenfalls nahezu unmöglich mit einem einzigen Computer, dafür bräuchte man ein riesiges Bot Netz.
Punkt 3 sehe ich auch nicht wirklich als kritisch an, denn die Automatisierung mithilfe der IE.au3 unterdrückt/blockiert/überschreibt keinerlei Inhalte und macht auch nichts anderes als ein normaler Besucher der Webseite, nur eben schneller. Störend wäre das noch viel weniger.
Punkt 4 wäre nur dann erfüllt wenn er vorhandene Angebote einlesen würde und die dadurch gesammelten Daten in irgendeiner Form nutzt, wie z.B. zur automatischen Bestimmung seiner eigenen Angebotspreise oder worauf das ganze eher abzielt auf das kopieren der Angebotstexte und Bilder. Davon war hier ebenfalls nie der Rede, es geht hier lediglich um das Einstellen neuer eigener Angebote.

Also wo sucht hier jemand Schlupflöcher? Die AGB sind doch eindeutig und verständlich und widersprechen in keinem Punkt der automatisierten Angebotseinstellung. Nicht umsonst bietet Ebay selbst eine API an, die von jedem Programmierer genutzt werden kann.

Naja das schliesst eine Automatisierung meiner Meinung nach nicht kategorisch aus, sondern soll nur verhindern, dass der Betrieb dadurch gestört wird:

"die das Funktionieren der eBay-Website stören können"
"unzumutbare oder übermäßige Belastung"
"störend in die eBay-Website eingreifen"

Alles nicht unbedingt gegeben wenn man nicht gerade eine Endlosschleife auf Ebay loslässt. Aber selbst dann würden die Ebay Server wohl nur müde lachen, dort greifen täglich Millionen Menschen zeitgleich zu...
Ebay bietet meinem Wissen nach im übrigen auch eine API für genau solche Zwecke an und stellt selbst entsprechende Programme zur Verfügung. Ob das auch für die Kleinanzeigen gilt weiß ich nicht, hat mich nie sonderlich interessiert.

Grundsätzlich würde ich aber eher winHTTP zur Automatisierung nutzen.

Per Live HTTP Headers und/oder Firebug kommt man spielend leicht an die Kategorie und Unterkategorie id's bzw Namen.
Hier mal 3 Beispielkategorien die ich mit Live HTTP Headers mitgeschnitten habe:

http://kleinanzeigen.ebay.de/anzeigen/p-anzeige-aufgeben-schritt2.html
POST /anzeigen/p-anzeige-aufgeben-schritt2.html HTTP/1.1
Host: kleinanzeigen.ebay.de
Referer: http://kleinanzeigen.ebay.de/anzeigen/p-anzeige-aufgeben.html




parentCategoryId=210&categoryId=223&attributeMap%5Bautoteile_reifen.art_s%5D=tuning_styling
parentCategoryId=161&categoryId=279&attributeMap%5Bkonsolen.art_s%5D=xbox
parentCategoryId=210&categoryId=211

Man muss nun also nur noch einen HTTP Post absetzen und je nach Kategorie den String unten ersetzen. Das selbe macht man dann mit dem zugehörigen Verkaufsformular, bzw kann man sich den ersten Schritt vermutlich ganz sparen weil im finalen abesenden POST vermutlich auch die Kategorie Info mitgeschickt wird.

Ich vermute mal es liegt daran wie du die Datei einliest. Standardmäßig öffnet fileread die Datei im Ansi oder UTF Mode. Wenn du sie binär einlesen willst musst du zuvor fileopen mit dem entsprechenden Flag für Binär Daten verwenden.

fileopen

MsgBox(0,"",IniRead("ben.ini","","Key",""))

1. Der Pfad zur ini ist vermutlich nicht vollständig, bin mir jedenfalls nicht sicher was iniread tut wenn nur ein Dateiname anstatt eines kompletten Pfades angegeben wurde. besser wäre es in jedem Fall so:

$test = IniRead(@scriptdir & "\ben.ini","","Key","")
; oder eben der korrekte Pfad zur ini, z.b.
$test = IniRead("C:\ben.ini","","Key","")

2. Deine ini ist keine standardkonforme ini Datei. Eini ini muss immer Sektionen, Schlüssel und Werte haben, Schlüssel und Wert werden mit "=" getrennt, Sektionen mit "[]" umschlossen:

[meinDaten]
Key=Test
Gebanntvon=??????????
Bangrund=?????????
Level=1
AdminLevel=0
...usw...

3. iniread erwartet eine standardkonforme ini wie oben beschrieben, ansonsten wird die Funktion beim parsen scheitern

4. Da du ja scheinbar mehr als einen Account verwalten willst bietet es sich an, anstatt jedem user eine eigene ini zu geben jedem user eine ini Sektion zu geben:

[Ben]
Key=Test
Gebanntvon=??????????
Bangrund=?????????
Level=1
AdminLevel=0


[Hans]
Key=Test2
...usw...


[Georg]
...

5. Um Redundanz zu vermeiden wäre eine CSV Struktur sinnvoller:

Username,Key,Gebannt von,Bangrund,Level,AdminLevel,...
Ben,Test,??????????,??????????,1,0,...
Hans,Test2,...
Georg,...

Würde ich auch mal vermuten. Hatte selbst schon Scripte die extrem langsam gestartet sind, was letzten Endes nur auftrat wenn der on access Virenscanner aktiv war. Bei mir lag es soweit ich mich erinnere an den UPX Einstellungen des Compilers.

Wozu sollte das Script admin Rechte brauchen? Ich sehe jedenfalls nichts, das darauf hindeuten würde. Das einzige was auffällt ist, dass mit einer ini Datei im Scriptverzeichnis gearbeitet wird, was bei aktiver Benutzerkontensteuerung probleme machen kann, sofern sich das Script in einem Standardwindows Verzeichnis (z.B. C:\programme\...) befindet. Stattdessen sollte man ini Dateien in den dafür gedachten Ordnern des Benutzers speichern (%APPDATA%\deinprogramm\...).

Du könntest ja mal testen ob das Problem auch unter Windows7 auftritt wenn die Benutzerkontensteuerung aktiv ist.

Eine andere potentielle Fehlerquelle ist mir hier noch aufgefallen:

_GDIPlus_MatrixScale($hMatrix, $iWidth / DllStructGetData($tBounds, "Width"), $iHeight / DllStructGetData($tBounds, "Height"), True)

Ein Blick in die Hilfe verrät, dass dllstructgetdata() eine 0 zurückgibt, wenn es einen Fehler gibt. Die Division durch 0 würde dein Script vermutlich sofort zum Absturz bringen.

Ob nun Registry oder ini... beides ist leicht gefunden und kann vom Benutzer gelöscht werden um die Laufzeit zu reseten.

Ein anderer Ansatz wäre folgender:

Du erstellst serverseitig bei jedem angeforderten Download eine individuelle exe deines Scriptes, welche das Downloaddatum in verschlüsselter Form enthält. Das könnte man zum Beispiel durch automatisierte Scripte, welche das Resources Feld der exe bearbeiten realisieren. Das erfordert natürlich, dass du ein entsprechendes PHP Script schreibst. Dein Lizenzkey den du dem Anwender zukommen lässt enthält dann die maximale Laufzeit in Tagen. Dein Script kann dann prüfen ob die Differenz zwischen aktuellem Datum und Downloaddatum noch in der Toleranz der Lizenzlaufzeit liegt. Ausserdem können aufgrund der serverseitigen und geheimen Verschlüsselung Manipulationen des Downloaddatums ausgeschlossen werden.

Probleme:

1. Ein erneuter Download würde die Laufzeit verlängern, das könnte man z.B. vermeiden, wenn man jeder individuellen exe auch noch Regeln für die zugehörigen Lizenzkeys mitgibt, welche regelmässig varieren. Du musst dann nur verhindern, dass man beliebig viele Lizenzkeys bekommen kann, was leider auch nicht wirklich möglich ist.
2. Manipulationen der Systemuhr würden den Schutz aushebeln.
3. Wie bei allen Autoit Scripten kann der Schutz leicht durch Decompilen abgeschaltet werden

Ein wirklich wirksamer Schutz kann meiner Meinung nach nur durch online Prüfungen und temporäres nachladen essentieller Programmteile realisiert werden, welche nur im Speicher zur Laufzeit vorhanden sind. Aber auch das würde einen Profi vermutlich kaum davon abhalten den Schutz auszuhebeln. Selbst die größten Softwarefirmen mit tausenden Programmierern finden keinen Weg um die illegale Nutzung effektiv zu verhindern.

Zitat von Shadowigor

Zur Synchronität musst du die Befehle einfach direkt hintereinander, am besten in einer Schleife, an jeden Server senden. Das sollte zeitlich eigentlich synchron genug sein.

Sollte das aufgrund der Menge der Clients und Netzwerklatenzen nicht der Fall sein, könnte man das ganze zeitlich synchronisieren. Das setzt vorraus, dass alle Clienten die selbe Uhrzeit haben (z.B. gemeinsamer Timeserver). Der Server kombiniert den Befehl dann mit einem Ausführungsdatum/zeitpunkt welche ausreichend in der Zukunft liegt, um Latenzprobleme zu umgehen. Alle Clienten warten nach Erhalt des Befehls ab bis diese Ausführungszeitpunkt erreicht wurde und starten dann zeitgleich mit der Ausführung.

Letzten Endes reden wir hier aber vermutlich nur von Latenzen im ms Bereich, was den Aufwand einer Synchronisation vermutlich nicht rechtfertigt.