Hallo, ich möchte Daten vom PC auf meinen Laptop kopieren. Als Zwischenspeicher dient mein USB Stick. Auf beiden Systemen ist Windows7 installiert. Die Dateinamen auf dem PC sind teilweise recht lang - also etwas mehr als 27 Zeichen. Auf meinem Laptop ist es nicht möglich diese zu kopieren. Auch manuell kann ich auf dem Laptop keine längeren Dateinamen vergeben. Da es auf dem PC jedoch möglich ist, gehe ich davon aus, dass sich das irgendwo einstellen lässt? Wo kann ich die Begrenzung herausnehmen? Ich glaube, es liegt daran, dass der Pfad auf dem Laptop wesentlich länger ist??!!
:
Verschoben durch User
Jürgen Hems schrieb: > ch glaube, es liegt daran, dass der Pfad auf dem Laptop wesentlich > länger ist Ja. Max 255 (Pfad+Dateiname) ist möglich. Peter
Das mit den 256 Byte Laenge scheint so gewollt zu sein: http://msdn.microsoft.com/en-us/library/aa365247.aspx Wie hast du die Dateien denn auf dem PC erzeugt? Kannst du die Dateien per Zip-File kopieren? Vielleicht kann der Entpacker lange Dateiname erzeugen. Eine andere Option ist, die Daten einzeln ueber Unterverzeichnisse zu kopieren, ggf. mit "subst /einem/sehr/sehr/langen/pafdnamen z:" auf ein Laufwerk zuweisen. Plan B: Knoppix booten und die Daten damit kopieren. Ab ca. 2007 kann Linux NTFS Dateisysteme auch schreibend einbinden. Allerdings habe ich mich mit Knoppix noch nie an einem Win7-eNTenFileSystem versucht, kann sein das es da wieder Aenderungen im Sinne des technischen Fortschritts gab, also schoen vorsichtig sein.
Ja. man sollte auf den Muell wie /user/applicationdata/bla/bla/bla/eigene dateien/bla verzichten und die eigenen Dateien nach c:/mydata/ verschieben.
Delta Oschi schrieb: > /user/applicationdata/bla/bla/bla/eigene dateien/bla verzichten und die > eigenen Dateien nach c:/mydata/ verschieben. Also soll Benutzer bla seine bla-Dateien nach mydata schieben, Hacker Oschi? Muss es zwingend c:\mydata heißen?
Delta Oschi schrieb: > Ja. man sollte auf den Muell wie > /user/applicationdata/bla/bla/bla/eigene dateien/bla verzichten und die > eigenen Dateien nach c:/mydata/ verschieben. das sind gerade mal C:\Dokumente und Einstellungen\mein_name\Anwendungsdaten knapp 60 Zeichen, dann hat man noch mehr als 190 als reserve - das wird wohl reichen. Wie lang ist denn nun der Pfad wo die daten hinsollen, schreibst du ganze romane in den Dateinamen?
Vielleicht liegts daran das der PC NTFS als Dateisystem benutzt und der Laptop FAT32?
Spackmahal schrieb: > Muss es zwingend c:\mydata heißen? Der \ in Pfadnamen ist eine der grundlegenden Innovationen von M$ im Bereich Dateisysteme und Alleinstellungsmerkmal seiner Betriebsysteme. Allerdings fiel M$ einmal fast einer feindlichen Übernahme durch Agenten aus dem *nix-Umfeld zum Opfer: die Verbrecher bauten klammheimlich einen Umsetzmechanismus in die Filesyste-Treiber ein, der dafür sorgen sollte, daß man auch / benutzen kann. Wie aus zuverlässiger Quelle zu vernehmen war, hat Bill Gates höchstpersönlich diesen Plan jedoch in letzter Sekunde vereiteln können, indem er nur Kommandointerpreter zuließ, die auf \ bestehen und den / penetrant als Kennzeichen für Kommandozeilen interpretieren. So ist die Welt gerade nochmal an einer *nix-Katastrophe vorbeigeschrammt, die die heile M$-Welt glatt zum Einsturz gebracht hätte.
Uhu Uhuhu schrieb: > Der \ in Pfadnamen ist eine der grundlegenden Innovationen von M$ im > Bereich Dateisysteme und Alleinstellungsmerkmal seiner Betriebsysteme. / ging nicht, da MS-DOS seine Konventionen ursprünglich von CP/M geklaut hatte und das dort für Optionen verbraten war. Sie hätten mit Einführung von Unterverzeichnissen natürlich auch bei VMS klauen können, dann hiesse das nun SYS$C:[mydata]file.txt;17 und wäre dank der Klammern auf hiesigen Tastaturen auch nicht besser erreichbar. Bei IBMs Mainframe-OS CMS konnten sie nicht klauen, denn dessen Filesystem beherrschte zu diesem Zeitpunkt auch noch kein Unterverzeichnisse.
A. K. schrieb: > / ging nicht, da MS-DOS seine Konventionen ursprünglich von CP/M geklaut > hatte und das dort für Optionen verbraten war. Tja, der \ war eben eine echte Innovation...
Die 260 Zeichen als maximale Pfadlänge sind wirklich nicht besonders viel. Das ist halt wieder einmal ein Relikt aus der Vergangenheit, das man aus Kompatibilitätsgründen nicht ändern möchte. Zu Windows-3.1- Zeiten, wo die Dateinamen noch kurz und die Festplatten noch klein waren, mag das gereicht haben. Aber heute, wo Windows teilweise sogar auf Servern mit vielen Terabyte Festplattenkapazität eingesetzt wird, stößt man ständig auf solche Probleme. Fragt mal eure Server-Admins :) Auf meinem schon 5 Jahre alten Dell-Laptop war folgende Datei vom Hersteller vorinstalliert:
1 | c:\Programme\Dell\EMBASSY Trust Suite by Wave Systems\Embassy Trust Suite\EMBASSY Security Setup\program files\Wave Systems Corp\EMBASSY Security Setup\plugins\passwords.swp\webinterface\images\AccessingToolkitIcon.gif |
Das sind immerhin 218 Zeichen. Macht man von der Festplatte einen datei- weisen Backup auf einen Server, landen die Dateien dort natürlich nicht im Root-Verzeichnis, sondern irgendwo in der dritten oder vierten Ver- zeichnisebene. Damit ist die 260-Zeichengrenze schnell überschritten. Es ist natürlich auch ziemlich sinnfrei, für Datei- und Verzeichnisnamen zwar 255 Zeichen zuzulassen, für gesamte Pfade aber kaum mehr.
Yalu X. schrieb: > Es ist natürlich auch ziemlich sinnfrei, für Datei- und Verzeichnisnamen > zwar 255 Zeichen zuzulassen, für gesamte Pfade aber kaum mehr. Das war bestimmt als Kopierschutz gedacht ;-)
Yalu X. schrieb: > Es ist natürlich auch ziemlich sinnfrei, für Datei- und Verzeichnisnamen > zwar 255 Zeichen zuzulassen, für gesamte Pfade aber kaum mehr. Wieso, im Minimalfall ist der Unterschied 3. C:\
Dieses 260er Limit gilt nicht durchgehend, sondern ist abhängig vom verwendeten API. Wenn man Pech hat, dann schreibt einer mit einem Unicode-API einen elend langen Pfad auf die Platte und der nächste versucht auf dem normalen Weg damit etwas anzufangen. Da kommt Freude auf. http://msdn.microsoft.com/en-us/library/aa365247.aspx
per FindFile kriegst du so dann aber das verkürzte 8.3 alias.
A. K. schrieb: > Wenn man Pech hat, dann schreibt einer mit einem Unicode-API einen > elend langen Pfad auf die Platte und der nächste versucht auf dem > normalen Weg damit etwas anzufangen. Da kommt Freude auf. Früher (mittlerweile ist das möglicherweise gefixt), konnte man seine Mitmenschen (vor allem aber die Admins) ärgern, wenn man von einem Nicht-Windows-Client aus auf einem Windows-Server eine Datei anlegt, die mit einem Punkt (.) endet. Ich habe das einmal gemacht, weil ich nicht wusste, dass das eigentlich verboten ist (auch wieder so ein Relikt aus DOS-Zeiten). Etwa ein Jahr später, als der Admin das Filesystem auf eine neue Festplatte umziehen wollte, hat er mich voller Panik angerufen und gefragt, was denn das für eine komische Datei sei. Er konnte sie trotz höchster Admin-Rechte weder kopieren, umbenennen noch löschen. Ich habe sie für ihn dann umbenannt. Hätte mein Nicht-Windows-System zu dem Zeitpunkt nicht mehr zur Vefügung gestanden, hätten wir ein kleines Problem gehabt :) Spackmahal schrieb: > per FindFile kriegst du so dann aber das verkürzte 8.3 alias. Wäre das bei den Dateien mit dem Punkt am Ende auch gegangen? Ist vielleicht wichtig für ein anderes Mal ;-)
Yalu X. schrieb: > Früher (mittlerweile ist das möglicherweise gefixt), konnte man seine > Mitmenschen (vor allem aber die Admins) ärgern, wenn man von einem > Nicht-Windows-Client aus auf einem Windows-Server eine Datei anlegt, die > mit einem Punkt (.) endet. Wem sagst du das. Die Mac-User hatten eine Vorliebe dafür. Dieser Ärger war allerdings deshalb auch ein Sargnagel für AFP, nun müssen die Macs SMB sprechen oder es gibt für sie nix. Kann die Netapp nicht. Seit die Windows Server (mit AFP) dadurch abgelöst wurden ist Ruhe. Ich denke, das Problem wurde zwischenzeitlich "gefixt", indem die alten Macs, die ohne Zusatzsoftware nur AFP konnten, inzwischen ausgestorben sind. > Ich habe sie für ihn dann umbenannt. Hätte mein Nicht-Windows-System zu > dem Zeitpunkt nicht mehr zur Vefügung gestanden, hätten wir ein kleines > Problem gehabt :) Möglicherweise hätte der POSIX API auch geholfen. Die Mac-User hatten allerdings auch so andere Sonderzeichen, mit denen sie Windows-User auf die Nerven gehen konnten. Das war zwar kein technisches Problem, sah aber Sch..sse aus.
ich hab mal unter W98 eine Datei versehentlich in Com1 umbenannt. Danach bin ich sie einfach nicht mehr losgeworden, liess sich nicht mehr löschen.
Ein Leerzeichen am Ende eines Filenamens macht auch immer wieder Spass.
A. K. schrieb: > Kann die Netapp nicht. Könnte aber sein, dass das auch nur eine Frage der Zeit ist bzw. des nötigen zahlungskräfitgen Kunden, an den NetApp ein paar der Dinger verkaufen kann, wenn sie's mit AFP ausliefern ... Tjaja, Windows-Nutzer diskutieren drüber, ob man am Ende eines Dateinamens einen Punkt haben darf oder nicht, während sich die IEEE-1003.1-Arbeitsgruppe (ehemals Posix) damit schwer tut, ob sie nun eine Empfehlung verabschieden soll, dass man sich in Dateinamen auf druckbare Zeichen beschränken soll. ;-) Bislang gilt für Posix, dass alles außer Vorwärtsstrich und Nullzeichen ein zulässiges Zeichen im Dateinamen ist. (Am meisten verärgern dabei die Posixer gar nicht mal x-beliebige Zeichen, sondern Dinge wie Newlines im Dateinamen.) Kann man eigentlich Windows immer noch damit ärgern, wenn man eine Datei namens "nul" auf einem USB-Stick anlegt und diesen dann unter Windows auslesen will? ;-)
zumindest nicht bei win7: C:\>echo "test" > "test " Zugriff verweigert
Jörg Wunsch schrieb: > Kann man eigentlich Windows immer noch damit ärgern, wenn man eine > Datei namens "nul" auf einem USB-Stick anlegt und diesen dann unter > Windows auslesen will? ;-) Ja, kann man, da wird nämlich nix angelegt ;-) Grad mal getestet.
Der Entwickler schrieb: > ich hab mal unter W98 eine Datei versehentlich in Com1 umbenannt. Danach > bin ich sie einfach nicht mehr losgeworden, liess sich nicht mehr > löschen. Das erinnert mich an die Krankheit, wenn man DateiName.c (das vielleicht ein unbedarfter Nutzer mal so angelegt hat) in dateiname.c umbenennen möchte. Das geht nicht, zumindest nicht auf direktem Weg. Das zugrunde liegende Dateisystem (NTFS) ist halt case sensitive, d. h. es merkt sich sehr wohl die Schreibweise, in der der Dateiname erzeugt worden ist. Das Windows-API dagegen ist case insensitive, sodass aus seiner Sicht DateiName.c und dateiname.c einundderselbe Name sind, damit lehnt es die Umbenennung ab. Geht nur, indem man einen (völlig anderen) Zwischennamen einführt und zweistufig umbenennt.
Jörg Wunsch schrieb: > Könnte aber sein, dass das auch nur eine Frage der Zeit ist bzw. > des nötigen zahlungskräfitgen Kunden, an den NetApp ein paar der > Dinger verkaufen kann, wenn sie's mit AFP ausliefern ... Heute noch? Glaub ich nicht. Protokolle gibts bei Netapp nur gegen Einwurf kleiner Münzen und da jeder Mac heute SMB kann wär das eine überflüssige Ausgabe. Denn den Laden, der eine Netapp hat, aber nirgends Windows, den möchte ich mal sehen.
Der Entwickler schrieb: > Jörg Wunsch schrieb: >> Kann man eigentlich Windows immer noch damit ärgern, wenn man eine >> Datei namens "nul" auf einem USB-Stick anlegt und diesen dann unter >> Windows auslesen will? ;-) > > Ja, kann man, da wird nämlich nix angelegt ;-) Grad mal getestet. Ich rede davon, dass eine solche Datei bereits auf dem USB-Stick existiert (weil sie auf einem Nicht-Windows-OS angelegt worden ist) und vielleicht auch noch einen den Windows-Nutzer interessierenden Inhalt hat :), aber auf einem solchen OS ausgelesen werden soll.
Spackmahal schrieb: > zumindest nicht bei win7: > > C:\>echo "test" > "test " > Zugriff verweigert Unter XP gehts noch.
A. K. schrieb: > Denn den Laden, der eine Netapp hat, aber nirgends > Windows, den möchte ich mal sehen. Ein AppleStore? ;-) OK, vermutlich stellen die sich keine NetApp hin.
Der Entwickler schrieb: > Jörg Wunsch schrieb: >> Kann man eigentlich Windows immer noch damit ärgern, wenn man eine >> Datei namens "nul" auf einem USB-Stick anlegt und diesen dann unter >> Windows auslesen will? ;-) > > Ja, kann man, da wird nämlich nix angelegt ;-) Grad mal getestet. Man kann eine "nul" oder "null"-Datei mit *nix erstellen. Die wird dann auch von win 7 gelesen.
Spackmahal schrieb: > C:\>echo "test" > "test " > Zugriff verweigert XP legt ein File ohne das Leerzeichen an. Die Macs via AFP freilich liessen es drin. Das war ja der Knackpunkt. Und während man den Punkt hinten dran wenigstens noch (auf dem Mac) sehen konnte, fiel das Leerzeichen nicht wirklich gross auf.
A. K. schrieb: > XP legt ein File ohne das Leerzeichen an. lustiges XP: Die Datei kann sowohl als "test" und auch als "test " geöffnet werden.
Spackmahal schrieb: > Bei Macs ist die Dateiendung ".ihateapple" verboten.
1 | [xxx:~/tmp] j% uname -a |
2 | Darwin xxx 11.3.0 Darwin Kernel Version 11.3.0: Thu Jan 12 18:47:41 PST 2012; root:xnu-1699.24.23~1/RELEASE_X86_64 x86_64 |
3 | [xxx:~/tmp] j% touch unsinn.ihateapple |
4 | [xxx:~/tmp] j% ls -a |
5 | . .. unsinn.ihateapple |
6 | [xxx:~/tmp] j% rm unsinn.ihateapple |
Aha.
Spackmahal schrieb: > lustiges XP: Die Datei kann sowohl als "test" und auch als "test " > geöffnet werden. Klar. Das geht nämlich auch dann, wenn das File als "test" angelegt wurde. Der Windows-API wirft die Leerzeichen am Ende über Bord. Beim Anlegen und beim Lesen.
Anderswo gibts solche Spässe aber auch. Im AIX JFS hatte ich es mal geschafft, ein File mit einem völlig leeren Namen anzulegen, also Länge 0. Ich weiss nicht wie ich das geschafft hatte. Jedenfalls blieb das Ding hartnäckig auf der Kiste liegen, weil sich kein Weg fand, es anzusprechen, zu löschen, was auch immer. Denn allein schon die Arbeitsweise des File/Pfad-Parsers von Unix liess ein Ansprechen eines solchen Files vermutlich überhaupt nicht zu.
A. K. schrieb: > Denn allein schon die > Arbeitsweise des File/Pfad-Parsers von Unix liess ein Ansprechen eines > solchen Files vermutlich überhaupt nicht zu. fsdb, das arbeitet auf der Basis von inode-Nummern, aber ein solches Tool dürfte AIX's JFS nicht besessen haben.
Jörg Wunsch schrieb: > fsdb, das arbeitet auf der Basis von inode-Nummern, aber ein solches > Tool dürfte AIX's JFS nicht besessen haben. Gibt es. Aber so wichtig, dass ich auf diese Ebene runter wollte, war das Thema nicht. Blieb es halt liegen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.