Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Přejmenování pomocí 8.3 konvence nefungovalo? Tj. "uchopit" soubor jako "Sníme~1.png" ?
Pokud to takto lze, tak to stejně asi není univerzální řešení. Když bude nepovolený znak v prvních 6 znacích, je to nepoužitelné.
Pokud je nepovolený znak na začátku, měl by krátký název obsahovat znaky jiné/náhradní, ne?
Mi třeba nejde v průzkumníkovi vytvořit složku začínající tečkou, v Total Commanderu to jde.
V příkazové řádce taky a v každém rozumnějším správci souborů to jde. Průzkumník je vždycky nouzovka.
To je asi bug v exploreru, systému to jinak nevadí. Ale může to přinést jiné problémy, třeba kdysi jsem měl takové soubory na ftp a normálně se v nějakém webovém rozhraní nezobrazovaly, takže se adresář zobrazoval jako prázdný. Při pokusu o smazání to ale házelo chybu, že prázdný není.
Tohle je ještě dobré, rozdrbal jste to v systému, který nekorektně pracuje s NTFS, ale mně se podařilo při instalaci Visual SVN importovat šložku c:\temp\projects do složky c:\VisualSVN\projects - tolik vnořených složek jste ještě neviděli :-) Pak jsem to asi 2 hodiny likvidoval, jediné řešení je jít v té struktuře tak hluboko, jak to jde (asi 256 znaků?) pak vzít tu složku co vidíte, přesunout ji nahoru, smazat větev, která zbyla a v té přesunuté zase začít znovu. Brrr... Nechápu, že to dovolí vytvořit něco, co pak nejde smazat :(
Holt další historická zátěž průzkumníka :-( Jádro systému bez potíží umožní programům pracovat s cestami až ~32760 znaků dlouhými, nespoléhá-li tento program na berličky (zpětné) kompatibility.
Novější Total Commander by už teď snad neměl mít s těmito cestami problém, ale převážná většina ostatního sw, včetně mnoha nástrojů OS samotného, bohužel má.
Na to jsi přišel jak, že Linux pracuje s NTFS nekorektně? NTFS jako takovému dvojtečka nevadí, resp. u názvu souboru je uveden jmenný prostor a pokud je nastaven na POSIX (hodnota 0), je dvojtečka korektním znakem. Je to naopak neschopností Windows, že se s takovou situací neumí slušně vypořádat. A nebo to tam neměl MS umožnit (je to jeho specifikace).
no ale Microsoft tvrdí na MSDN něco jiného: http://msdn.microsoft.com/en-us/library/aa365247%28VS.85%29.aspx
Kde je tedy pravda?
Tam nic jiného netvrdí. Pouze je tam doporučení, že když chceš mít jistotu, že s názvem souboru nebudou problémy v žádném OS (čímž míní ty svoje), máš se (mimo jiných věcí) vyhnout použití znaku dvojtečka. Nikde tam ale netvrdí, že jej pro PISIXový jmenný prostor použít nelze.
Taky se mi něco podobného stalo. Existují různé funkce pro práci se soubory, ty staré mají limit na cca 250-260 znaků (o něco méně/více než 256 co by člověk čekal). Jedna možnost je přesouvat, druhá to třeba substovat nebo nasdílet a mazat přes sdílení. Ono to smazat jde, akorát cesty používané v parametrech nesmí přesáhnout nějaký limit.
scrot -d 3 -c ~/screenshots/%Y-%d-%m_%s.png a ziadny problem
Ja by som skusil nejaky program na obnovenie zmazanych suborov. Tie nebudu citat filesystem cez windows api, a pri trochu stastia sa budu zaoberat aj nezmazanymi subormi.
Ono by stačilo zkontrolovat jestli jsou k souborům vytvořené 8.3 názvy a pak pracovat s těmi.
dir /x je zobrazí.
Musí se pak sice pracovact v cmd, čož je však na nějaké hromadné přejmenování nakonec stejně nejlepší.
I Total Commander umí (možná uměl, delší dobu jsem to nepotřeboval) pracovat v režimu 8.3 znaků na soubor.
cygwin s takymi nazvami robit nevie?
Ono se to chova srandovne treba pres Sambu - kdyz se nasdili soubory ktere obsahuji nepovolene znaky (casto po ripnuti CD a pojmenovani podle CDDB tam jsou uvozovky) pripadne nazvy filmu s dvojteckou - vse takoveto se objevi jako nahodny retezec :)
BTW: dvojtecka ve windows v nazvu souboru muze byt, jsou to tzv. NTFS streams, zavedene kvuli kompatibilite s applimi streamy v MacOsX 9 a nizsich.
Zkuste si treba:
D:\C>echo abcd > abcd.txt
D:\C>echo efgh > abcd.txt:efgh.txt
D:\C>more < abcd.txt
abcd
D:\C>more < abcd.txt:efgh.txt
efgh
Ve windows je to v soucasnosti pouzivane treba pro oznaceni stazeneho souboru ("Tento soubor pochazi z internetu, chcete ho opravdu spustit?"), ve streamu s nazvem ":Zone.Identifier"
Jj, streamy jsou prima věcička :). Tohle ale byly přímo soubory, ne streamy. Mimochodem třeba takový notepad sám o sobě streamy otevřít neumí, ale z příkazového řádku ho donutit lze, ovšem pouze v případě, že stream má „příponu“ .txt - pak ten stream umí i editovat a ukládat, jako by to byl soubor :).
Ja bych si dovolil rict, ze nazvy souboru s dvojteckama, stejne tak jako s diakritikou, je proste prasarna. Clovek ma vytvaret nebo zajistit vytvareni takovych nazvu souboru/adresaru, se kterymi nebudou mit ostatni systemy problem.
Bejvaly časy, kdy bych s tebou v tomhle i souhlasil. Byl jsem jedním z těch, co měli nepřekonatelnej „morální“ problém s tím, že s příchodem Windows 95 se do DOSu dostaly dlouhé názvy souborů (taky jsem to považoval za prasárnu). Doba pokročila, dnes si bez toho neumím život představit. A ačkoli vím, že používání diakritiky v názvech souborů s sebou může nést jisté potíže, v pohodě to používám. Ovšem nikdy jsem se nedostal tak daleko, abych jako jméno souboru (to před příponou) použil něco, co svou konstrukcí připomíná celý název jedné nejmenované politické strany ;) (ono by to ostatně ani nešlo, jednak kvůli délce a jednak kvůli tomu, že to obsahuje otazníky, což je pro název souboru ve Windows ještě větší zlo než dvojtečka ;).
- no jo je to magor, ale diky za ty seznamy...aspon neco pozitivniho po nem zustalo :-)
Jo, a soubory CON a PRN by se taky radsi nemeli vytvaret, co ... osobne povazuji soubory se znaky jako jsou dvojtecky nebo uvozovky za normalnejsi nez s diakritikou.
Bejvávalo a dlouho jsem to ctil. Dnes je naopak prasárna Windows, že stále neumí s někteými znaky nespadajícími do základní latinky, nejen "nepovolené znaky". Dobré OS to už vůbec neřeší.
Doma máme japonské a české Windows (7) a tu samou kombinaci Macky (starý 10.6, ale na Masoxu to platí odjakživa). Zatímco u jablek nedělají problém ani české znaky v názvech souborů a ani japonština a vše tam funguje hladce a bez okolků (české soubory na MacOS X v japonštině a opačně), tak na českých Windows je čeština OK, ale jakmile je v názvu souboru japonština, je zle. Programy hlásí neexistující cesty a eroří o život. Není to plošné, liší se program od programu (včetně systémových záležitostí). Platí to i opačně, na japonských Windows japonské filenames problém nedělají, ale jeden pitomý háček a je zasekáno na témže problému.
Na filesystému v tomto případě nesejde, dělá to všude i na synchronizovaných přes dropbox.
Díky příspěvku "Babči" níže už chápu kde je zakopán pes. Jsem si sice myslel, že to bude něco takového, ale popravdě, netušil jsem že i nejnovější Windows jsou stále takto "lokální" a znaky v názvech souborů přenášené "křížem mezi znakovými sadami" budou i dnes dělat brajgl. Dnes v globálním světě, kde vám z Číny přijdou soubory s čínskými názvy souborů, z japonska japonsky, z koreje hangulem nebo z dubaje v arabštine. :-)
Divím se že nikdo ještě nenavlhnul použít program WinHEX. Vždyť je to skoro nezbytný program třeba jako Wireshark.
Osobně si myslím že je to spíš chyba ovladače pro NTFS v Linuxu. Měl by být navržen tak, aby nezpůsobil potencionální problém někde jinde.
Když se už bavíme o souborových systémech tak za největší zvěrstvo které Microsoft spáchal považuji FAT32 a na druhém místě způsob jakým se identifikuje typ souborového systému FAT (FAT12, FAT16, FAT32). Místo aby používal položku v MBR k tomu určenou, tak souborový systém identifikuje podle velikosti FAT tabulky a počtu clusterů. Je zajímavé, že o této "vlastnosti" skoro nikdo neví a dokonce o ni mlčí i odborná literatura jako např. Jan Axelson - USB Mass Storage.
Což je pravděpodobně následek původu - diskety se na oddíly nerozdělovaly.
no pravděpodobně to s tím souvisí (tzn. že na disketě není MBR), ale na druhou stranu proč to nějak krkolomně počítat když je je v boot sectoru k dispozici název souborového systému?
No jo....wokna....
Vím, že komentář není přínosný.
pridam sa
> 2014
> problemy s dvojtečkou
Já se WIFTe pořád nemůžu zbavit dojmu, že seš prostě problémovej :-P
neni to omezeni NTFS, ale WindowsAPI
a smazat to jde jednoduse pomoci cmd>rd \\.\c:\neplatny:soubor.txt
viz: http://support.microsoft.com/kb/315226
Fuu, celá diskuze je mimo, kromě Marv-CZ, a jediný Václav nade mnou řešení nakousl správným směrem. WIFTe, pes je zakopaný jinde! :-)
Libor Foltýnek + J.D.: Ale jděte, Linux pracuje s NTFS správně. Soubory mohou v názvu mít libovolný znak kromě \0, tedy stejně jako u ext2/3/4 a dalších moderních filesystémů. Viz wiki. NTFS používá interně UTF-16. V názvu může být v extrémním případě myslím dokonce i UTF-16 nevalidní řetězec 16-bitových hodnot. Vyhrazených je jen několik jmen.
speciální soubory: $MFT, $MFTMirr, $LogFile, $Volume, $AttrDef, $Bitmap, $Boot, $BadClus, $Secure, $Upcase
speciální adresáře: . (tečka), $Extend
Průzkumíkem nelze vytvořit, či přejmenovat soubory tak, aby měly v názvu : \ / * ? " < > |, končily mezerou, obsahovaly ASCII znaky 1-31 atd. Dokonce takové soubory nelze průzkumníkem ani otevřít, zahlásí, že soubor nebyl nalezen.
To nám nekoresponduje s omezeními v NTFS, že?
Nakonec to není taková záhada. Existuje totiž ANSI API pro přístup k souborům, a Unicode API pro přístup k souborům. Unicode API je tu s námi už mnoho let, přišlo s příchodem NTFS, které používá nativně UTF-16. Proč tedy nejde s průzkumínkem přejmenovat screenshoty zmíněné z článku? No v tom, že Průzkumník, i v roce 2014, ve Windows 8.1, používá ANSI API. ;-)
Je to jednak kvůli zpětné kompatibilitě, či prostě z archaických důvodů. IMHO Microsoft se bál, že přepnutím Průzkumníka na Unicode by způsobil, že běžný uživatel by začal příliš používat znaky, v ANSI API zakázané, a tím si znemožnil přístup k těmto souborům většině současných programů, čímž by si MS uškodil. Prostě do toho raději nehrabal. Dodnes 90% programů využívá stále pouze ANSI API.
Dále tu jsou archaismy, tím myslím např. vyhrazené názvy pro DOSová zařízení. Zkuste si v průzkumníku na NTFS oddíle vytvořit obyčejný texťák AUX.txt... Vyhrazená jsou jména CON, PRN, AUX, NUL, COM1 až COM9, LPT1 až LPT9. Dnes je to sice už nesmysl, ale je to prostě dáno léta neměnnou API (přes kterou to neprojde).
Pro práci s těmito soubory tedy potřebujete správce souborů, který využívá Unicode API. Ve Windows takový není, ovšem z příkazové řádky se k těmto souborům dostat lze. WIFT udělal chybu v tom, že používal běžné cesty k souborům, pro ty windows využije ANSI API. Použijete-li unicode zápis cesty, dostaneme se už dál.
Pro připomenutí, ve windows se používá hned několik formátů cesty k souboru:
C:\user\docs\Letter.txt
/user/docs/Letter.txt
C:Letter.txt
\\Server01\user\docs\Letter.txt
\\?\UNC\Server01\user\docs\Letter.txt
\\?\C:\user\docs\Letter.txt
C:\user\docs\somefile.ext:alternate_stream_name
./inthisdir
../../greatgrandparent
více viz: http://en.wikipedia.org/wiki/Path_(computing)
Pouze cesty začínající \\?\ implikují použití Unicode API. Řešení je tedy jednoduché, přepsat cestu na unicode zápis.
del "C:\folder\file"
del "\\?\C:\folder\file"
Tento způsob nezprovozníte u všeho, protože daný program musí tyto adresy sám podporovat – správně rozeznat formát adresy a předat ho příslušné funkci fopen.
Btw. mezi API jsou ještě další rozdíly, např. ANSI api podporuje relativní adresy, zpětná i běžná lomítka, Unicode API pouze absolutní adresy a zpětná lomítka. Dále jsou rozdíly v povolených délkách názvů souborů, a celých cest, ale je v tom pekelný bordel, co se kdy počítá za znak a co ne (složka//soubor.txt, složka/../../soubor.txt) vs. kombinace ANSI/Unicode přístupu vs. použitý filesystem.
Další zajímavé čtení ohledně lomítek je např. tu http://superuser.com/questions/176388/why-does-windows-use-backslashes-f.... WIFTe určitě o tomto napiš článek na 5 kapitol :D
Tohle je všechno strašně krásný, ale:<ol><li>Já ty soubory nechci smazat</li><li>Já s nima potřebuju <em>normálně</em> dělat</li></ol>Závěr je pořád stejný: jestli nechci mít problémy a nechci řešit „kudy se kua zase k tomu souboru dostat“, tak bych měl prostě na dvojtečky v názvu souboru zapomenout.
A ne, opravdu nebudu tuhle legrácku opakovat jen proto, abych si ověřil, jakým způsobem bych se k souborům s dvojtečkou v názvu ve Windows dostal. I když nepopírám, že by to bylo zajímavé bádání. Nicméně je to jako řešit, jak zajistit, aby nezakryté hovno nesmrdělo, když je úplně nejjednodušší ho zakrýt. Jakkoli jsou Windowsy v mnohém hodně dobré, tak v některých věcech jsou až dětsky blbé. Jako ostatně spousta jiných věcí.
- Já ty soubory nechci smazat
- Já s nima potřebuju normálně dělat
Závěr je pořád stejný: jestli nechci mít problémy a nechci řešit „kudy se kua zase k tomu souboru dostat“, tak bych měl prostě na dvojtečky v názvu souboru zapomenout. A ne, opravdu nebudu tuhle legrácku opakovat jen proto, abych si ověřil, jakým způsobem bych se k souborům s dvojtečkou v názvu ve Windows dostal. I když nepopírám, že by to bylo zajímavé bádání. Nicméně je to jako řešit, jak zajistit, aby nezakryté hovno nesmrdělo, když je úplně nejjednodušší ho zakrýt. Jakkoli jsou Windowsy v mnohém hodně dobré, tak v některých věcech jsou až dětsky blbé. Jako ostatně spousta jiných věcí. https://diit.cz/blog/jak-tucnak-vydrbal-s-woknama-aneb-kdyz-ma-soubor-v-nazvu-dvojtecku/diskuse#comment-688461 +Já se pokusím ještě doplnit/vyvrátit WIFTovo tvrzení, že bez písmenek diskových jednotek se nejde obejít. Ono je to totiž částečně pravda, ale i lež :) Windows si automaticky vytvoří minimálně jednotku C (dříve to bývalo i A) a do této jednotky už je možné mountovat další jednotky jak komu libo a jak zvyklý. Klidně si můžete udělat strukturu adresářů jako na Linuxu :). Slouží k tomu NTFS mount pointy (http://superuser.com/questions/536886/what-happens-when-windows-runs-out...). No a k těmhle adresářům lze přistoupit bez jména jednotky. Tedy \mnt\drive1\myfile.txt jako na Linuxu...akorát s opačným lomítkem.
Jo a ještě jedna věc: Málo se to ví, ale Windows mají dokonce i symlinky :) Ale to jenom bokem.
？：＜＄％＞＼＂ Když se chce, všechno jde.txt >>> http://uloz.to/xZR5XPqP/kdyz-se-chce-vsechno-jde-txt
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.