Mi pensas, ke vi, kiel mi, vidis tiajn vojojn pli ol unu fojon !!! Grava____Nova____!!! Ne forigu!!!Ordo n-ro 98819-649-B de la 30-a de februaro 1985 pri la nomumo de Ivan Aleksandroviĉ Kozlov kiel provizora deĵoranta estro de la fako por subteni kompaniajn VIP-klientojn kaj organizi komercajn kunvenojn flanke.doc.
Kaj ofte vi ne povos tuj malfermi tian dokumenton en Vindozo. Iuj homoj praktikas solvon en formo de disko-mapado, aliaj uzas dosieradministrantojn, kiuj povas labori kun longaj vojoj: Far Manager, Total Commander kaj similaj. Kaj multaj pli spektis kun malgajo kiel la PS-skripto, kiun ili kreis, en kiun multe da laboro estis investita kaj kiu funkciis kun bruego en la testa medio, en produktmedio senhelpe plendis pri neebla tasko: La specifita vojo, dosiernomo aŭ ambaŭ estas tro longaj. La plene kvalifikita dosiernomo devas esti malpli ol 260 signoj, kaj la dosierujo devas esti malpli ol 248 signoj.
Kiel rezultas, 260 signoj sufiĉas "ne nur por ĉiuj". Se vi interesiĝas transiri la limojn de tio, kio estas permesita, bonvolu raporti al la kato.
Jen nur kelkaj el la malfeliĉaj konsekvencoj de limigado de dosiervoja longo:
- estas dosierujo sur la servilo, ekzemple, D:DataSharedAccounting, kiu estas dividita per SMB kaj muntita al uzantoj kiel retdisko S; uzantoj kreas dosierojn, kiujn administrantoj/skriptoj ne povas legi kiam ili aliras loke de la servilo, ĉar la absoluta vojo estas pli longa ol la reto vojo;
- ;
- ;
- dum migrado de datumoj de aliaj sistemoj, kiuj havas malpli severajn limigojn pri padolongo, en la nova medio kelkaj el ili fariĝos neatingeblaj sen dancado per tamburino;
- ;
- ktp ...
Iomete deflankiĝante de la temo, mi rimarkas, ke por DFS Replication la problemo priparolata en la artikolo ne estas terura kaj dosieroj kun longaj nomoj sukcese vojaĝas de servilo al servilo (se, kompreneble, ĉio alia estas ).
Mi ankaŭ ŝatus atentigi vin pri tre utila utileco, kiu helpis min pli ol unufoje . Ŝi ankaŭ ne timas longajn vojojn, kaj ŝi povas fari multon. Sekve, se la tasko resumas al kopiado/transdono de dosieraj datumoj, vi povas ĉesi tie. Se vi bezonas ludi lertaĵojn kun dosiersistemaj alirkontrolaj listoj (DACLs), rigardu for . Malgraŭ ĝia progresinta aĝo, ĝi bonege funkciis en Windows 2012 R2. metodoj de aplikado estas pripensitaj.
Mi interesiĝis pri instruado kiel labori kun longaj PowerShell-vojoj. Ĉe li estas preskaŭ kiel en barba ŝerco pri Ivano Caraviĉ kaj Vasilisa la Bela.
Rapida maniero
Ŝanĝu al Linukso kaj ne zorgu pri Vindozo 10/2016/2019 kaj ebligu la taŭgan gruppolitikan agordon / ĝustigu la registron. Mi ne detale detenos pri ĉi tiu metodo, ĉar... Estas jam multaj artikoloj pri ĉi tiu temo en la Interreto, ekzemple, .
Konsiderante, ke la plej multaj kompanioj havas multajn, por paroli milde, ne la lastajn versiojn de operaciumoj, ĉi tiu metodo estas rapida nur por skribi sur papero, krom se, kompreneble, vi estas unu el tiuj bonŝanculoj, kiuj havas malmultajn heredajn sistemojn kaj Windows 10. /2016/2019 regas supere .
La longa vojo
Ni tuj faru rezervon ĉi tie, ke la ŝanĝoj ne influos la konduton de Windows Explorer, sed ebligos uzi longajn vojojn en PowerShell cmdlets, kiel Get-Item, Get-ChildItem, Remove-Item, ktp.
Unue, ni ĝisdatigu PowerShell. Ĝi estas farita unu, du, tri fojojn.
- Ni ĝisdatigas la .NET Framework al versio ne pli malalta ol 4.5. La operaciumo devas esti almenaŭ Windows 7 SP1/2008 R2. Vi povas elŝuti la nunan version , legu pli da informoj .
- kaj instalu Windows Management Framework 5.1
- Ni rekomencas la maŝinon.
Laboremaj homoj povas fari la paŝojn priskribitajn supre permane, maldiligentaj homoj povas fari ĝin helpe de SCCM, politikoj, skriptoj kaj aliaj aŭtomatigaj iloj.
La nuna versio de PowerShell troveblas de la variablo $PSVersionTable. Post la ĝisdatigo ĝi devus aspekti kiel ĉi tio:
Nun kiam vi uzas cmdletojn Get-ChildItem kaj similaj anstataŭ la kutima vojo ni uzos laŭvorta Vojo.
La padformato estos iomete malsama:
Get-ChildItem -LiteralPath "?C:Folder"
Get-ChildItem -LiteralPath "?UNCServerNameShare"
Get-ChildItem -LiteralPath "?UNC192.168.0.10Share"
Por la komforto konverti vojojn de la kutima formato al la formato laŭvorta Vojo vi povas uzi ĉi tiun funkcion:
Function ConvertTo-LiteralPath
Param([parameter(Mandatory=$true, Position=0)][String]$Path)
If ($Path.Substring(0,2) -eq "") {Return ("?UNC" + $Path.Remove(0,1))}
Else {Return "?$Path"}
}
Bonvolu noti, ke kiam oni fiksas la parametron laŭvorta Vojo Vi ne povas uzi ĵokerojn (*, ? kaj tiel plu).
Krom la parametro laŭvorta Vojo, en la ĝisdatigita versio de PowerShell cmdlet Get-ChildItem ricevis la parametron profundo, per kiu vi povas agordi la nestoprofundon por rekursiva serĉo, mi uzis ĝin kelkfoje kaj estis kontenta.
Nun vi ne devas zorgi, ke via PS-skripto erarvas laŭ la longa dorna vojo kaj ne povos vidi malproksimajn dosierojn. Ekzemple, ĉi tiu aliro multe helpis min kiam mi skribis skripton por restarigi la "provizoran" atributon de dosieroj en DFSR-dosierujoj. Sed tio estas alia historio, kiun mi provos rakonti en alia artikolo. Mi antaŭĝojas pri interesaj komentoj de vi kaj sugestas vin fari la enketon.
Utilaj ligoj:
Nur registritaj uzantoj povas partopreni la enketon. , bonvolu.
Ĉu la problemo de longaj vojoj rilatas al vi?
-
Jes
-
Estis grava, sed jam decidis
-
Ĝi malhelpas, sed ne multe
-
Mi ne pensis pri tio, ĉio ŝajnas funkcii
-
Neniu
-
Aliaj (bonvolu specifi en komentoj)
155 uzantoj voĉdonis. 25 uzantoj sindetenis.
fonto: www.habr.com