Archiv verlassen und diese Seite im Standarddesign anzeigen : Win 7 x64 - Beim Kopieren: Dateiname zu lang!
twodoublethree
2010-06-25, 23:32:16
Lieber 3DCentler,
heute hatte meine Freundin an ihrem Rechner ein Problem, sie konnte Daten von ihrem USB-Stick nicht vollständig auf den PC übertragen da einige Dateinamen zu lang seien.
Der USB-Stick wurde mit einem Windows-XP Rechner befüllt und hat NTFS als Dateisystem.
Der Rechner (bzw die Rechner, habe es auch an meinem Laptop ausprobiert) laufen beiden mit Windows 7 x64 (einmal Home Premium, einmal Professional). Beide haben auf den Ziellaufwerken NTFS.
Windows gibt mir als Fehlermeldung an, der DateiNAME sei zu lang, jedoch kann ich den Ordner komplett auf C: kopieren, nur auf C:\Users\...\Desktop\ bricht er mir mit der Fehlermeldung ab.
NTFS sollte doch aber genügend Freiraum bieten für längere Pfadlängen?
Habe auf allen Rechnern die Dropbox-Software installiert, kann es irgendwie damit zusammenhängen?
Weiß echt nicht weiter, vielen Dank für die Hilfe!
HeldImZelt
2010-06-25, 23:41:06
Nicht nur der Dateiname, auch der gesamte Pfad ist limitiert. Wenn da viele Verzeichnisse drin sind, reicht's u.U. nicht mehr für die Dateinamen.
Hatte ich auch beim Kopieren von ein paar AutoCAD-Dateien... Sehr ärgerlich das ganze
Aus irgendwelchen Kompatibilitätsgründen ist bei Windows Pfad+Dateiname auf zusammen 255 Zeichen limitiert, obwohl NTFS eigentlich wesentlich mehr kann.
PS: Unter Linux werden die Fähigkeiten des Dateisystems nicht künstlich beschnitten.
DELIUS
2010-06-26, 00:27:49
Das mit den 255 Zeichen kenne ich auch.
Aber was will mir Wikipedia hiermit sagen bezüglich des Pfadnamens?
Unterschiede ab NTFS 1.X (gegenüber FAT) (http://de.wikipedia.org/wiki/NTFS#Unterschiede_ab_NTFS_1.X_.28gegen.C3.BCber_FAT.29)
eine maximale Länge des kompletten Pfadnamens von 32.767 Zeichen, einige Backupprogramme funktionieren jedoch nur bis zu 256 Zeichen.
Dachte die 255 ist die Summe aus Pfadname und Dateiname?
Aber was will mir Wikipedia hiermit sagen bezüglich des Pfadnamens?
Wikipedia schreibt was mit NTFS theoretisch möglich ist.
Dachte die 255 ist die Summe aus Pfadname und Dateiname?
So sieht es in der Praxis leider auch aus, da Windows nicht mehr erlaubt. Das ist kein Problem von NTFS, sondern eine Design-Entscheidung von Microsoft, damit uralt-Software keine Probleme macht.
HeldImZelt
2010-06-26, 00:41:23
Die Zahlen dürften sich sogar nur auf ANSI Zeichen beziehen. Bei Unicode könnten, je nach Häufigkeit, dynamisch Abstriche auftreten, weil stellenweise mit mehr als 8Bit angesprochen werden muss.
Neosix
2010-06-26, 01:13:56
existiert ein fix für windows der das ganze aufhebt? ich stöße immer wieder auf diese beschränkung, und finde sie mehr als ärgerlich. kann man sie irgend wie deaktivieren?
DELIUS
2010-06-26, 02:04:50
existiert ein fix für windows der das ganze aufhebt? ich stöße immer wieder auf diese beschränkung, und finde sie mehr als ärgerlich. kann man sie irgend wie deaktivieren?
Gute Frage und auch ich habe Unverständnis, warum diese Barriere immer noch für NTFS besteht (seit 1993, also ca. 17 Jahre!!)
Warum bietet man den Anwendern von "nicht-uralt-Software" keine Möglichkeit an, NTFS im vollem Umfang zu nutzen? Patch her und gut ist.
Lokadamus
2010-06-26, 07:45:07
existiert ein fix für windows der das ganze aufhebt? ich stöße immer wieder auf diese beschränkung, und finde sie mehr als ärgerlich. kann man sie irgend wie deaktivieren?mmm...
Nein, hab ich zumindest nichts von gehört.Gute Frage und auch ich habe Unverständnis, warum diese Barriere immer noch für NTFS besteht (seit 1993, also ca. 17 Jahre!!)
Warum bietet man den Anwendern von "nicht-uralt-Software" keine Möglichkeit an, NTFS im vollem Umfang zu nutzen? Patch her und gut ist.Was ist für dich "nicht uralt Software"? Software für XP ist aufjedenfall uralt Software, auch wenn es letztes Jahr erst herausgekommen ist ;).
Nebenbei frag ich mich, wie man es überhaupt schafft, an das Limit ranzukommen. Das klappt doch nur bei Dateinamen wie "Wie ziehe ich die linke Socke richtig an und verwechsle es nicht mit der rechten Socke.doc.ppt" und das in Ordnern ala "C:\User\gaaaanz langer Name\Eigene Dateien\privat\ganz privat\geheim!!!\nicht gucken!!!\Anleitung für alltägliche Sachen\".
Rooter
2010-06-26, 11:06:33
Z.B. mit Namen in dieser Art:
Freundin Jenny Kaiserslautern Nackt Jung Sexy Geil Exfreundin Exfrau Nutte Hure Kontakt Chat Anal Preteen Xxx Pussy Votze Muschi Rasiert Lolit Boobs.jpg
:D
Verkürzen der einzelnen Ordnernamen könnte bei dem Problem helfen.
MfG
Rooter
Malabolge
2010-06-26, 12:49:24
Z.B. mit Namen in dieser Art:
Freundin Jenny Kaiserslautern Nackt Jung Sexy Geil Exfreundin Exfrau Nutte Hure Kontakt Chat Anal Preteen Xxx Pussy Votze Muschi Rasiert Lolit Boobs.jpg
:D
Verkürzen der einzelnen Ordnernamen könnte bei dem Problem helfen.
MfG
Rooter
Du hast ORAL vergessen !:biggrin::rolleyes::wink::D:D:D:D:biggrin::biggrin::biggrin::biggrin:
Wie konnte das nur Passieren.
BT: vielleicht dateien nicht nur in "C:\....\....\....\eigene dateien\..." speichern
aber das ist ja wohl zu "unbequem" , da muss man ja im Speichern Dialog "denken" !
][immy
2010-06-26, 13:40:48
Das mit den 255 Zeichen kenne ich auch.
Aber was will mir Wikipedia hiermit sagen bezüglich des Pfadnamens?
Dachte die 255 ist die Summe aus Pfadname und Dateiname?
grundsätzlich kann NTFS das auch mit 32k zeichen. aber einige programme können das wie beschrieben nicht.
dazu gehört z.B. auch visual studio (auch 2010 noch) welches leider auf 255 zeichen begrenzt ist
aber der windows explorer sollte es eigentlich nicht sein, erst recht nicht bei windows 7
hast du vielleicht irgendwelche kompabiltätseinstellungen bei windows 7 eingestellt?
funktioniert das kopieren aus der kommandozeile mittels xcopy?
BoRaaS
2010-06-26, 15:01:42
Ansonsten wenn du unbedingt in den langen Pfad kopieren mußt, dann nutze doch das alte Programm "subst".
subst <langer Ordnerpfad> <neuer Laufwerksbuchstabe>
Anschließend kopierst du die Dateien in den neuen Lauwerksbuchstaben.
Danach kannst du den Laufwerksbuchstaben mit Subst wieder "auflösen".
Der_Donnervogel
2010-06-26, 15:24:44
Bei http://msdn.microsoft.com/en-us/library/aa365247(v=VS.85).aspx gibt es eine Erklärung wie das mit den Pfadlängen ist (Maximum Path Length Limitation).
Die Windows API unterstützt theoretisch bis zu 260 Zeichen als Pfadlänge. Da kommen aber noch ein paar Zeichen weg (bis zu 12) die von Windows genutzt werden.
Es gibt aber eine Ausnahme davon. Windows besitzt auch Pfadfunktionen die Unicodezeichen verwenden. Dort sind Pfadlängen bis zu 32767 Zeichen möglich, sofern man vor den Pfad das Prefix \\?\ setzt und jede Pfadkomponente nicht länger als 255 Zeichen ist.
Ich habs ausprobiert und der Explorer (Vista) bringt keinen Fehler wenn man das Prefix vor einen Pfad setzt. Er scheint es also zu kennen. Ich vermute allerdings, dass man schon einen alternativen Dateimanager bräuchte, wo man das Prefix nicht immer angeben muss. Ansonsten wäre es ziemlich lästig in der Bedienung. Außerdem gibts sicher einige Programme die damit nicht klar kommen. Wobei man sich dort damit behelfen könnte, z.B. mit subst weitere virtuelle Laufwerksbuchstaben die dann auf ein Unterverzeichnis verweisen, sodass Software die lange Pfade nicht unterstützt, darüber zugreifen kann.
HeldImZelt
2010-06-26, 18:19:05
Es gibt aber eine Ausnahme davon. Windows besitzt auch Pfadfunktionen die Unicodezeichen verwenden. Dort sind Pfadlängen bis zu 32767 Zeichen möglich, sofern man vor den Pfad das Prefix \\?\ setzt und jede Pfadkomponente nicht länger als 255 Zeichen ist.Das hat nichts mit Unicode zu tun. Das 'shell user interface' unterstützt nur kurze Pfade, was letztlich eine politische Entscheidung ist.
twodoublethree
2010-06-30, 14:51:46
Vielen Dank für die Informationen, dann muss man sich eben was einfallen lassen um das Problem zu umgehen!
Selle
2010-07-12, 14:01:51
Schon etwas älter der Thread, aber ich schreib trotzdem mal ;)
Versuch mal mit dem Unstoppable Copier (http://www.chip.de/downloads/Unstoppable-Copier_13005271.html). Getestet hab ich das zwar nicht mit zu langen Namen, allerdings nutze ich das immer wenn das Dateisystem jammert die Datei wäre zu groß (DVD Image zb.) obwohl genug Platz ist.
Lokadamus
2010-07-12, 18:25:22
Versuch mal mit dem Unstoppable Copier (http://www.chip.de/downloads/Unstoppable-Copier_13005271.html). Getestet hab ich das zwar nicht mit zu langen Namen, allerdings nutze ich das immer wenn das Dateisystem jammert die Datei wäre zu groß (DVD Image zb.) obwohl genug Platz ist.mmm...
:| Was für ein Filesystem benutzt, dass Windows solche Fehlermeldungen bringt? NTFS kann es nicht sein oder wie groß sind deine Dateien?
Das mit den langen Namen hängt mit dem Pfad zusammen, unter dem Win7 die Profile abspeichert. Ein leicht lösbares Problem, indem man entweder ein paar Sachen umbennent und kürzer macht oder in einen eigenen Ordner direkt unter der Root abspeichert ;).
Auch wenn der Thread schon etwas älter ist, dafür auch lang nicht so alt wie das Problem ansich - Namen oder Pfade kürzen kann doch keine Lösung sein, wenn M$ hier die Dateistruktur in Windows mit immer tieferen Pfaden anlegt, aber im Gegensatz hier keine Abhilfe schafft, schliesslich lässt M$ sich Windoof ja ordentlich bezahlen, wohingegen es bei Linux bezgl. Pfadlängen offensichtlich keine Probleme gibt - und das ist kostenlos!
Dieses Problem ist dabei nicht das einzige was sich schon Jahre/Jahrzehnte unverständlicherweise durch M$ Software zieht.
Lokadamus
2011-06-24, 20:50:37
mmm...
Das Problem ist eben die Altlast mit der Kompatibilität zu älterer Software.
So lange es noch Fat32- Partitionen gibt, wird es diese Begrenzung wohl geben. Und Fat macht sich auf USB- Sticks momentan sehr gut ...
Das Windows 7 64bit im Jahre 2011 da noch nicht flexibel reagieren kann ist eigentlich schon armseelig, man sollte meinen das ein Betriebssystem der Xten Generation das Filesystem eines Datenträgers erkennen und entsprechend individuell bei Interaktionen behandeln kann, bzw. mit dem Anwender entsprechend kommuniziert.
Der immer grösser werdende Massenspeicher (HDDs mit 1TB und grösser werdend) impliziert eigentlich auch ein höherer Bedarf an feinerer Kategorisierung der Daten - Ordnerstrukturen mit genaueren Bezeichnungen und/oder tieferen Pfaden die diese feinere Archivierung ermöglichen.
Ist jetzt natürlich alles eher philosophisch zu betrachten, da wir uns ja nicht in einem M$-Forum befinden (als wenn es was brächte wenn doch), als Mitleidender hilfts aber sich darüber mal ausgetextet zu haben ;)
Wenn man sich mal die Googleergebnisse zum Thema betrachtet, so sieht man, dass es ja doch ein bereits verbreitetes Problem darstellt und M$ sich doch mal wieder kreativ zeigen sollte.
Bäh... als Gast texte ich einfach zu viel, vielleicht sollt ich mich anmelden und mal über nvidia, amd und physX lästern :lol:
Gnafoo
2011-06-27, 18:28:43
Das Problem liegt in den alten APIs. Wenn die einmal garantiert haben, dass bei PATH_MAX Schluss ist, dann kann man das Limit nicht einfach im Nachhinein erhöhen. Neues Filesystem hin- oder her.
Nehmen wir mal ein älteres Programm, das vom Betriebssystem irgendwo einen Dateinamen erfragt. Das reserviert sich beispielsweise einen Puffer der eben PATH_MAX groß ist und lässt den dann per API mit dem Namen füllen. Wenn du jetzt die API änderst, dann kann es passieren, dass über den Pufferrand geschrieben wird und das Programm abschmiert oder eine Sicherheitslücke entsteht. So etwas kriegt man einfach nicht mehr raus, wenn es einmal drin ist.
Die einzige Möglichkeit besteht darin, die API um neue Funktionen zu erweitern, was Microsoft ja wohl auch getan hat (siehe den Post von Der_Donnervogel). Nur muss das auch in den Programmen ankommen und gerade in diesem Fall reichen die kurzen Pfadlängen meist aus, weshalb sich das wohl wenig verbreitet. Wenn die neue API nicht durchgängig benutzt wird, dann bringt das ganze wenig.
Insofern ist es bedauerlich, dass die Beschränkung überhaupt irgendwann in der API entstanden ist. Es wäre sicher besser gewesen, wenn man das gleich ohne Beschränkungen entworfen hätte. Leider macht das String-Handling in C so etwas immer unnötig kompliziert.
Afaik besteht das Problem prinzipiell auch unter Linux, nur da fällt es leichter, an den Limits zu drehen, weil die Software in der Regel im Quellcode vorhanden ist und man diese entweder selbst compiliert oder vom Distributor bezieht, der entsprechend compilierte Pakete anbietet. Windows hat einfach viel mehr – vor allem auch alten – Binärcode, der von irgendwelchen festen APIs ausgeht und entsprechend ist man um die Stabilität dieser APIs bemüht.
Black-Scorpion
2011-06-27, 18:38:50
Schon etwas älter der Thread, aber ich schreib trotzdem mal ;)
Versuch mal mit dem Unstoppable Copier (http://www.chip.de/downloads/Unstoppable-Copier_13005271.html). Getestet hab ich das zwar nicht mit zu langen Namen, allerdings nutze ich das immer wenn das Dateisystem jammert die Datei wäre zu groß (DVD Image zb.) obwohl genug Platz ist.
NTFS benutzen und nicht FAT32. ;) Das kann eben nur mit Dateien bis GB umgehen. Nicht umsonst sind aus Kompatibilitätsgründen auch auf DVDs die Dateien nur 2GB groß. ;)
seba86
2013-01-06, 22:26:35
Für die Suchmaschinen-Besucher:
Mit der Linux-CD klappt das Kopieren zulanger Datennamen, mit Unstoppable Copier nicht, letzteres kopiert NICHT und zeigt auch KEINE Fehler an.
Rooter
2013-01-07, 00:52:13
Nicht umsonst sind aus Kompatibilitätsgründen auch auf DVDs die Dateien nur 2GB groß. ;)1GB ;)
MfG
Rooter
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.