Windows, PowerShell, ແລະເສັ້ນທາງຍາວ

ຂ້າ​ພະ​ເຈົ້າ​ຄິດ​ວ່າ​ທ່ານ, ຄື​ຂ້າ​ພະ​ເຈົ້າ, ໄດ້​ເຫັນ​ເສັ້ນ​ທາງ​ເຊັ່ນ​ນີ້​ຫຼາຍ​ກ​່​ວາ​ຫນຶ່ງ​ຄັ້ງ !!! ສຳຄັນ____ໃໝ່____!!! ຫ້າມລຶບ!!! ເລກທີ 98819-649-ບ ລົງວັນທີ 30 ກຸມພາ 1985 ກ່ຽວກັບການແຕ່ງຕັ້ງ Ivan Aleksandrovich Kozlov ເປັນຫົວຫນ້າພະແນກຊົ່ວຄາວສໍາລັບການສະຫນັບສະຫນູນລູກຄ້າ VIP ຂອງບໍລິສັດແລະຈັດກອງປະຊຸມທຸລະກິດຢູ່ sidelines.doc.

ແລະເລື້ອຍໆທ່ານຈະບໍ່ສາມາດເປີດເອກະສານດັ່ງກ່າວໃນ Windows ໄດ້ທັນທີ. ບາງຄົນປະຕິບັດການແກ້ໄຂບັນຫາໃນຮູບແບບຂອງແຜນທີ່ແຜ່ນ, ຄົນອື່ນໃຊ້ຕົວຈັດການໄຟລ໌ທີ່ສາມາດເຮັດວຽກກັບເສັ້ນທາງຍາວ: Far Manager, Total Commander ແລະອື່ນໆ. ແລະອີກຫຼາຍໆຄົນໄດ້ເບິ່ງດ້ວຍຄວາມໂສກເສົ້າຍ້ອນວ່າສະຄິບ PS ທີ່ເຂົາເຈົ້າສ້າງ, ເຊິ່ງມີການລົງທຶນຫຼາຍແລະເຮັດວຽກກັບສຽງດັງໃນສະພາບແວດລ້ອມການທົດສອບ, ໃນສະພາບແວດລ້ອມການຜະລິດຈົ່ມຢ່າງສິ້ນຫວັງກ່ຽວກັບວຽກງານທີ່ເປັນໄປບໍ່ໄດ້: ເສັ້ນທາງທີ່ລະບຸ, ຊື່ໄຟລ໌, ຫຼືທັງສອງແມ່ນຍາວເກີນໄປ. ຊື່ໄຟລ໌ທີ່ມີຄຸນສົມບັດຄົບຖ້ວນຕ້ອງມີໜ້ອຍກວ່າ 260 ຕົວອັກສອນ, ແລະຊື່ໄດເລກະທໍລີຕ້ອງມີໜ້ອຍກວ່າ 248 ຕົວອັກສອນ.
ດັ່ງທີ່ມັນປາກົດ, 260 ຕົວອັກສອນແມ່ນພຽງພໍ "ບໍ່ພຽງແຕ່ສໍາລັບທຸກຄົນ." ຖ້າທ່ານສົນໃຈທີ່ຈະໄປເກີນຂອບເຂດຂອງສິ່ງທີ່ອະນຸຍາດ, ກະລຸນາອ້າງອີງເຖິງແມວ.

ນີ້ແມ່ນພຽງແຕ່ບາງຜົນສະທ້ອນທີ່ໂຊກບໍ່ດີຂອງການຈໍາກັດຄວາມຍາວຂອງເສັ້ນທາງໄຟລ໌:

• ມີໂຟນເດີຢູ່ໃນເຊີບເວີ, ສໍາລັບການຍົກຕົວຢ່າງ, D:DataSharedAccounting, ເຊິ່ງຖືກແບ່ງປັນຜ່ານ SMB ແລະເຊື່ອມຕໍ່ກັບຜູ້ໃຊ້ເປັນ drive ເຄືອຂ່າຍ S; ຜູ້ໃຊ້ສ້າງໄຟລ໌ທີ່ admins / scripts ບໍ່ສາມາດອ່ານໄດ້ໃນເວລາທີ່ເຂົ້າເຖິງໃນທ້ອງຖິ່ນຈາກເຄື່ອງແມ່ຂ່າຍ, ເພາະວ່າ ເສັ້ນທາງຢ່າງແທ້ຈິງແມ່ນຍາວກວ່າເສັ້ນທາງເຄືອຂ່າຍ;
• ການຊິ້ງຂໍ້ມູນຜິດພາດສຳລັບໂປຣໄຟລ໌ໂຣມມິງ;
• ບັນຫາກັບການຟື້ນຟູຈາກສໍາເນົາເງົາ;
• ໃນເວລາທີ່ການເຄື່ອນຍ້າຍຂໍ້ມູນຈາກລະບົບອື່ນໆທີ່ມີຂໍ້ຈໍາກັດທີ່ເຂັ້ມງວດຫນ້ອຍກ່ຽວກັບຄວາມຍາວຂອງເສັ້ນທາງ, ໃນສະພາບແວດລ້ອມໃຫມ່ຂອງພວກມັນບາງສ່ວນຈະກາຍເປັນທີ່ບໍ່ສາມາດເຂົ້າເຖິງໄດ້ໂດຍບໍ່ມີການເຕັ້ນລໍາກັບ tambourine;
• ຂໍ້ມູນທີ່ບໍ່ຖືກຕ້ອງໃນເວລາທີ່ຄິດໄລ່ຂະຫນາດແລະຈໍານວນໄຟລ໌ໃນໂຟນເດີ;
• ແລະອື່ນໆ ...

ຄວາມແຕກຕ່າງເລັກນ້ອຍຈາກຫົວຂໍ້, ຂ້າພະເຈົ້າສັງເກດວ່າສໍາລັບ DFS Replication ບັນຫາທີ່ສົນທະນາໃນບົດຄວາມແມ່ນບໍ່ຂີ້ຮ້າຍແລະໄຟລ໌ທີ່ມີຊື່ຍາວປະສົບຜົນສໍາເລັດຈາກເຄື່ອງແມ່ຂ່າຍໄປຫາເຄື່ອງແມ່ຂ່າຍ (ຖ້າ, ແນ່ນອນ, ທຸກສິ່ງທຸກຢ່າງອື່ນແມ່ນ. ເຮັດຖືກຕ້ອງ).

ຂ້າພະເຈົ້າຍັງຢາກຈະດຶງດູດຄວາມສົນໃຈຂອງທ່ານໄປຫາສິ່ງທີ່ເປັນປະໂຫຍດຫຼາຍທີ່ໄດ້ຊ່ວຍຂ້າພະເຈົ້າອອກຫຼາຍກວ່າຫນຶ່ງຄັ້ງ ໂຈນປຸ້ນ. ນາງຍັງບໍ່ຢ້ານເສັ້ນທາງຍາວ, ແລະນາງສາມາດເຮັດໄດ້ຫຼາຍຢ່າງ. ດັ່ງນັ້ນ, ຖ້າຫາກວ່າວຽກງານທີ່ຕົ້ມລົງໄປການຄັດລອກ / ໂອນຂໍ້ມູນໄຟລ໌, ທ່ານສາມາດຢຸດຢູ່ທີ່ນັ້ນ. ຖ້າທ່ານຕ້ອງການຫຼິ້ນ tricks ກັບບັນຊີລາຍຊື່ການຄວບຄຸມການເຂົ້າເຖິງລະບົບໄຟລ໌ (DACLs), ເບິ່ງໄປ subinacl. ເຖິງວ່າຈະມີອາຍຸສູງສຸດຂອງມັນ, ມັນປະຕິບັດໄດ້ດີໃນ Windows 2012 R2. ທີ່ນີ້ ວິທີການຄໍາຮ້ອງສະຫມັກແມ່ນພິຈາລະນາ.

ຂ້ອຍສົນໃຈສອນວິທີເຮັດວຽກກັບເສັ້ນທາງ PowerShell ຍາວ. ກັບລາວມັນເກືອບຄືກັບເລື່ອງຕະຫລົກທີ່ມີຫນວດກ່ຽວກັບ Ivan Tsarevich ແລະ Vasilisa the Beautiful.

ວິທີທີ່ໄວ

ສະຫຼັບໄປໃຊ້ Linux ແລະບໍ່ຕ້ອງກັງວົນກ່ຽວກັບ Windows 10/2016/2019 ແລະເປີດໃຊ້ການຕັ້ງຄ່ານະໂຍບາຍກຸ່ມທີ່ເຫມາະສົມ / ປັບການລົງທະບຽນ. ຂ້າ​ພະ​ເຈົ້າ​ຈະ​ບໍ່​ຢູ່​ໃນ​ວິ​ທີ​ການ​ນີ້​ໃນ​ລະ​ອຽດ​, ເພາະ​ວ່າ ... ມີຫຼາຍບົດຄວາມກ່ຽວກັບຫົວຂໍ້ນີ້ຢູ່ໃນອິນເຕີເນັດ, ສໍາລັບຕົວຢ່າງ, ນີ້.

ພິຈາລະນາວ່າບໍລິສັດສ່ວນໃຫຍ່ມີຫຼາຍ, ເຮັດໃຫ້ມັນອ່ອນໂຍນ, ບໍ່ແມ່ນການສະບັບຫລ້າສຸດຂອງລະບົບປະຕິບັດການ, ວິທີການນີ້ແມ່ນໄວພຽງແຕ່ສໍາລັບການຂຽນໃນເຈ້ຍ, ເວັ້ນເສຍແຕ່, ແນ່ນອນ, ທ່ານແມ່ນຫນຶ່ງໃນຜູ້ທີ່ໂຊກດີທີ່ມີລະບົບມໍລະດົກຫນ້ອຍແລະ Windows 10. /2016/2019 ປົກຄອງ.

ທາງຍາວ

ໃຫ້ຈອງທັນທີທີ່ນີ້ວ່າການປ່ຽນແປງຈະບໍ່ມີຜົນກະທົບຕໍ່ພຶດຕິກໍາຂອງ Windows Explorer, ແຕ່ຈະເຮັດໃຫ້ມັນເປັນໄປໄດ້ທີ່ຈະໃຊ້ເສັ້ນທາງຍາວໃນ PowerShell cmdlets, ເຊັ່ນ Get-Item, Get-ChildItem, Remove-Item, ແລະອື່ນໆ.

ກ່ອນອື່ນ, ໃຫ້ອັບເດດ PowerShell. ມັນເຮັດຫນຶ່ງ, ສອງ, ສາມເທື່ອ.

1. ພວກເຮົາອັບເດດ .NET Framework ເປັນເວີຊັ່ນບໍ່ຕໍ່າກວ່າ 4.5. ລະບົບປະຕິບັດການຕ້ອງເປັນຢ່າງໜ້ອຍ Windows 7 SP1/2008 R2. ທ່ານສາມາດດາວນ໌ໂຫລດສະບັບປະຈຸບັນ ທີ່ນີ້, ອ່ານຂໍ້ມູນເພີ່ມເຕີມ ທີ່ນີ້.
2. ດາວໂຫລດ ແລະຕິດຕັ້ງ Windows Management Framework 5.1
3. ພວກເຮົາ reboot ເຄື່ອງ.

ຄົນທີ່ເຮັດວຽກໜັກສາມາດເຮັດຕາມຂັ້ນຕອນທີ່ໄດ້ອະທິບາຍໄວ້ຂ້າງເທິງດ້ວຍຕົນເອງ, ຄົນຂີ້ຄ້ານສາມາດເຮັດໄດ້ດ້ວຍການຊ່ວຍເຫຼືອຂອງ SCCM, ນະໂຍບາຍ, scripts ແລະເຄື່ອງມືອັດຕະໂນມັດອື່ນໆ.

ເວີຊັນປັດຈຸບັນຂອງ PowerShell ສາມາດພົບໄດ້ຈາກຕົວແປ $PSVersionTable. ຫຼັງຈາກການປັບປຸງ, ມັນຄວນຈະເປັນແບບນີ້:

ໃນປັດຈຸບັນໃນເວລາທີ່ການນໍາໃຊ້ cmdlets ເອົາລາຍການເດັກນ້ອຍ ແລະຄ້າຍຄືກັນແທນທີ່ຈະເປັນປົກກະຕິ ເສັ້ນທາງ ພວກເຮົາຈະນໍາໃຊ້ LiteralPath.

ຮູບແບບເສັ້ນທາງຈະແຕກຕ່າງກັນເລັກນ້ອຍ:

Get-ChildItem -LiteralPath "?C:Folder"
Get-ChildItem -LiteralPath "?UNCServerNameShare"
Get-ChildItem -LiteralPath "?UNC192.168.0.10Share"

ເພື່ອຄວາມສະດວກໃນການປ່ຽນເສັ້ນທາງຈາກຮູບແບບປົກກະຕິໄປສູ່ຮູບແບບ LiteralPath ທ່ານສາມາດນໍາໃຊ້ຟັງຊັນນີ້:

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"}
}

ກະລຸນາສັງເກດວ່າໃນເວລາທີ່ກໍານົດພາລາມິເຕີ LiteralPath ທ່ານບໍ່ສາມາດໃຊ້ຕົວແທນ (*, ? ແລະອື່ນໆ).

ນອກເຫນືອໄປຈາກພາລາມິເຕີ LiteralPath, ໃນສະບັບປັບປຸງຂອງ PowerShell cmdlet ເອົາລາຍການເດັກນ້ອຍ ໄດ້ຮັບພາລາມິເຕີ ຄວາມເລິກ, ທີ່ທ່ານສາມາດກໍານົດຄວາມເລິກຂອງຮັງສໍາລັບການຄົ້ນຫາ recursive, ຂ້າພະເຈົ້າໄດ້ໃຊ້ມັນສອງສາມເທື່ອແລະພໍໃຈ.

ດຽວນີ້ເຈົ້າບໍ່ຕ້ອງກັງວົນວ່າສະຄຣິບ PS ຂອງເຈົ້າຈະຫຼົງທາງໄປຕາມເສັ້ນທາງທີ່ມີໜາມຍາວ ແລະຈະບໍ່ສາມາດເຫັນໄຟລ໌ທີ່ຢູ່ໄກໄດ້. ຕົວຢ່າງ, ວິທີການນີ້ຊ່ວຍຂ້ອຍຫຼາຍເມື່ອຂຽນສະຄິບເພື່ອຕັ້ງຄຸນລັກສະນະ "ຊົ່ວຄາວ" ຂອງໄຟລ໌ໃນໂຟນເດີ DFSR. ແຕ່ນັ້ນແມ່ນເລື່ອງອື່ນ, ເຊິ່ງຂ້ອຍຈະພະຍາຍາມບອກໃນບົດຄວາມອື່ນ. ຂ້າພະເຈົ້າຫວັງວ່າຈະໄດ້ຄໍາເຫັນທີ່ຫນ້າສົນໃຈຈາກທ່ານແລະແນະນໍາໃຫ້ທ່ານເຮັດການສໍາຫຼວດ.

ການເຊື່ອມຕໍ່ທີ່ເປັນປະໂຫຍດ:
docs.microsoft.com/ru-ru/dotnet/api/microsoft.powershell.commands.contentcommandbase.literalpath?view=powershellsdk-1.1.0
docs.microsoft.com/en-us/powershell/module/microsoft.powershell.management/get-childitem?view=powershell-5.1
stackoverflow.com/questions/46308030/handling-path-too-long-exception-with-new-psdrive/46309524
luisabreu.wordpress.com/2013/02/15/theliteralpath-parameter

ພຽງແຕ່ຜູ້ໃຊ້ລົງທະບຽນສາມາດເຂົ້າຮ່ວມໃນການສໍາຫຼວດ. ເຂົ້າ​ສູ່​ລະ​ບົບກະລຸນາ.

ບັນຫາຂອງເສັ້ນທາງຍາວແມ່ນກ່ຽວຂ້ອງກັບທ່ານບໍ?

• ແມ່ນ​ແລ້ວ

• ມີຄວາມກ່ຽວຂ້ອງ, ແຕ່ໄດ້ຕັດສິນໃຈແລ້ວ

• ມັນແຊກແຊງ, ແຕ່ບໍ່ຫຼາຍປານໃດ

• ຂ້າພະເຈົ້າບໍ່ໄດ້ຄິດກ່ຽວກັບມັນ, ທຸກສິ່ງທຸກຢ່າງເບິ່ງຄືວ່າຈະເຮັດວຽກ

• ບໍ່​ມີ

• ອື່ນໆ (ກະລຸນາລະບຸໃນຄໍາເຫັນ)

155 ຜູ້ໃຊ້ລົງຄະແນນສຽງ. 25 ຜູ້ໃຊ້ງົດ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com