Xcopy – „insufficient memory”

Popularne polecenie copy robi na pierwszy rzut oka to samo, z tą różnicą, iż nie jest wstanie podołać zadaniu duplikowania katalogów mieszczących się wewnątrz folderu z którego kopiujemy. Aby zaradzić temu problemowi Microsoft wprowadził nowszą wersję copy, nazwaną Xcopy (eXtended Copy). Narzędzie to, obecne w systemie Windows do dzisiaj często pomaga mi w sytuacjach wyglądających na beznadziejne (kiedy graficzne kopiowanie za pomocą przeciągania lub metody „kopiego-pejsta” wykonywane przez explorer.exe rozkłada bezradnie ręce z różnych powodów) ma jednak jedną poważną wadę. Jest nią cytowany w tytule komunikat „insufficient memory” na którym ten użyteczny programik kończy swoje działanie. Błąd ten zgłaszany jest w momencie, gdy kopiowany plik ma ścieżkę bezwzględną ( pełna ścieżka dostępu wraz z literą dysku ) dłuższą niż 254 znaki. A ponieważ dzisiejsze systemy plików obsługują dłuższe ścieżki, ta wada pozornie drobna wada xcopy robi się bardzo istotna.
Rozwiązaniem jest oczywiście znalezienie alternatywnego narzędzia które będzie miało podobną składnię. Pierwszym strzałem było xxcopy które zachowuje się bardzo podobnie, jednak nie identycznie. Jednakże ono też nie jest pozbawione wad. Najważniejszą jest fakt, że aby otrzymać dostęp do części istotnych ficzerów konieczne jest wykupienie licencji. Bliższe informacje można uzyskać na stronie programu.

Narzędziem, które polecam wszystkim (szczęśliwym 😉 ) użytkownikom Windows 7 oraz (nie)szczęśliwym użytkownikom Windows Vista ponieważ jest ono dostępne jako składnik systemu operacyjnego, oraz wszystkim innym po ściągnięciu resource kit’a do ich systemów, jest robocopy. narzędzie to, którego nazwa się wzięła od „Robust File Copy”, jest naprawdę potężnym przy wszelkich manipulacjach dużą ilością plików. dobry opis opcji programu znajduje się pod tym adresem w Wikipedii.

Układ współrzędnych w Mailach, czyli jak odpisywać LOGICZNIE

Przed chwilą odbyłem z moim przyjacielem TeMPOraLem Dyskusję na temat konwencji odpisywania na wiadomości email, a także o kierunku sortowania danych opatrzonych czasem.

Moim stanowiskiem jest odpowiadanie na górze, a także umieszczanie najświeższych informacji u góry strony/zasobu. Nie przemawia do mnie argument, że książki czytamy z góry na dół, gdyż książki nie są zawartością dynamiczną. Uważam, że sieć jest bardzo elastyczną strukturą, potrzebujemy najważniejsze i najświeższe informacje, a co za tym idzie dostęp do nich powinien być maksymalnie uproszczony.
Historia jest także bardzo ważnym elementem życia onLine, gdyż pozwala jednoznacznie określić ewentualne drobiazgi i przebieg jakiejś aktywności. Jednak jest to tylko w celach dokumentacyjnych. Życie toczy się tak szybko, iż ogarniamy najpilniejsze sprawy. Pamiętamy co było w liście/smsie/rssie godzinę czy dwie temu. Interesuje nas aktualny stan rzeczy dostępny w taki sposób, aby nie musieć się zastanawiać GDZIE on jest. Powinien być, jak mówi jedna Bardzo Ważna dla mnie Osoba „Na Oczach”. Takie ułożenie daje sortowanie malejące względem czasu. Najaktualniejsze dane są na wierzchu.

Argument że wiadomości powinny być posortowane rosnąco względem czasu można jeszcze przyjąć pod dyskusję, gdy ktoś uważa, że zawsze potrzebuje całą informację aby być wstanie przyswoić i zrozumieć aktualną wiadomość. Jednakże poglądu, że powinno się odpowiadać w treści czyjegoś komunikatu „cytując” jedynie, w żaden sposób nie potrafię uzasadnić jako rozsądne. Wyrywa się ułamki wypowiedzi z kontekstu, często bardzo podobnego gdy się dyskutuje niuanse zagadnienia, stąd łatwo o pomyłki w interpretacji. A kiedy konwersację prowadzi więcej osób, to bez zaawansowanego systemu śledzenia cytatów (zagadnienie: kto na co odpowiedział) cała energia czytającego/śledzącego zostaje zmarnowana na dojście do tego, kto jaki pogląd prezentuje.

Na koniec drobne pytanko do wszystkich którzy preferują ułożenie „najnowsze na dole”. Czy swój telefon komórkowy, tudzież klienta poczty elektronicznej przestawili na to, aby sam spis wiadomości był także samo posortowany? Z tego co wiem, wszystkie serwisy webowe obsługujące pocztę pokazują najnowsze wiadmości na górze. Telefony komórkowe tak samo. Readery rss podobnie. Klienty poczty elektronicznej także potwierdzają moją tezę.

To dlaczego na siłę zmieniać od dawna ubite szlaki kosztem szybkości dostępu w imię dziwnej filozofii ?

Podpisane Skrypty Power Shell

Dzisiaj próbowałem uruchomić skrypt Power Shell’a jako Pre-Build Step Visual Studio. Niestety jak na razie operacja ta ma status failed, jednakże przy okazji dowiedziałem się kilku istotnych rzeczy związanych z podejściem Power Shella do kryptografii i Infrastruktury klucza publicznego wogóle.

Na początek kilka słów o architekturze podsystemu kryptografii w windows. Oczywistym jest, że aby korzystać z dobrodziejstw podpisu/szyfrowania/logowania kryptograficznego potrzebujemy odpowiednich certyfikatów. Obecnie panującym standardem w tym zakresie jest X509 wraz z całą gamą standardów wykonawczych (ITU – ASN.1; RFC – różne noty aplikacyjno-standaryzacyjne).
Certyfikaty te znamy z codzienności, np. logowanie do banku, czy sklepu internetowego przez SSL. Możemy obejrzeć certyfikat, zapisać go jako plik. Ale tak na prawdę, to jest to jedynie cząstka prawdziwego narzędzia. Drugą stroną jest tak zwany klucz prywatny, który powinien być silnie strzeżony. Można (i często jest tak robione… Niestety) te klucze przechowywać także w plikach (np. pliki pfx). Ale to stanowi niebezpieczeństwo „Kompromitacji klucza” (Za RFC – Key Compromise). Dlatego praktycznie od początków, od Windows 2000 Microsoft udostępnia w ramach architektury systemu specjalne miejsce, gdzie w sposób bezpieczny i bardzo restrykcyjny udostępnia użytkownikom dostęp do ich certyfikatów i kluczy prywatnych.Jednak dawniej, przed epoką power Shella wykorzystanie tej przestrzeni i swobodne posługiwanie się certyfikatami było bardzo utrudnione. Istniały obiekty COM dostępne z Visual Basic; Istniały interface’y w C/C++. Jednak to było na tyle skomplikowane, że podpisane skrypty czy programy należały (i w sumie wciąż należą…. Niestety!) do rzadkości.

Power Shell zmienia stan rzeczy radykalnie. Aby podpisać jakikolwiek plik obsługujący SIP wystarczy świadomość jaki certyfikat z posiadanych może być do tego wykorzystany (kiedy użyjemy nieprawidłowego, zostaniemy na czerwono „okrzyczani”) oraz sam kawałek kodu w PS1, który chcemy oznaczyć jako zaufany.

Kwestię uzyskania odpowiedniego certyfikatu zostawię na następnego posta (zainteresowanych odsyłam do nmdlet’u get-help set-AuthenticodeSignature ),
natomiast pokażę fantastyczną składnię umożliwiającą wykorzystanie gotowego już certyfikatu z kluczem publicznym znajdującego się gdziekolwiek w bezpiecznym miejscu: Secure Store w rejestrze, bądź karta inteligentna (o plikach tu nie rozmawiamy, jak widać ;).
Należy przypomnieć że dawniej inaczej się odwoływało do usług Kart inteligentnych, a inaczej do składziku w rejestrze.
Teraz wszystko zostało zunifikowane do prostego uri

1
cert:\CurrentUser\My\[thumbrint certyfikatu]

. dzięki temu nie przejmujemy się więcej, gdzie ten certyfikat fizycznie jest, tym się zajmuje odpowiedni Dostawca Kryptografii (ang. Cryptografic Provider).
Żeby poznać, jaki certyfikat jest nam potrzebny utożsamiamy właściwy cert w widoku przystawki mmc certmgr.msc z jego odciskiem palca (Thumbprint) a następnie dla weryfikacji wydajemy polecenie powershell’a:

1
 Get-Childitem cert:\CurrentUser\my\

W odpowiedzi dostajemy listę wszystkich certyfikatów którymi możemy dysponować.
Po upewnieniu się, że wszystko jest w porządku, ostatecznie podpisujemy nasz skrypt:

1
 set-AuthenticodeSignature "[nazwa pliku]" (Get-Item cert:\CurrentUser\My\[thumbprint] )

Należy tu zauważyć że przy okazji wypływa potęga power shella – mając URI musimy pobrać obiekt .NET’owy, który dopiero może zostać wykorzystany przez cmdlet podpisujący.

efektem końcowym jest taka mniej więcej wstawka na końcu naszego skryptu:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
 # SIG # Begin signature block
# MIIQzwYJKoZIhvcNAQcCoIIQwDCCELwCAQExCzAJBgUrDgMCGgUAMGkGCisGAQQB
# gjcCAQSgWzBZMDQGCisGAQQBgjcCAR4wJgIDAQAABBAfzDtgWUsITrck0sYpfvNR
# AgEAAgEAAgEAAgEAAgEAMCEwCQYFKw4DAhoFAAQU7hpo4VUBv9KLt7qfk1yX4VDh
# yb2ggg5LMIIGgTCCBWmgAwIBAgIKTlmmBwAAAAABMDANBgkqhkiG9w0BAQUFADA/
# MQswCQYDVQQGEwJQTDENMAsGA1UEChMESVNDRzEhMB8GA1UEAxMYSVNDRyBJbnRl
# cm5hbCBJc3N1aW5nIENBMB4XDTA5MDkwMTEyMDEwMFoXDTEwMDkwMTEyMDEwMFow
# HzEdMBsGA1UEAwwUU3RhbmlzxYJhdyBXYXdzemN6YWswggEiMA0GCSqGSIb3DQEB
# AQUAA4IBDwAwggEKAoIBAQDavoPeVCITDaTC92URGp+mU4XVuA/+GwQ08ASxZ680
# kZ9ldDh0Kt6OmkEV2zuOQjO5jWXtHaStfxkR2Hc+/o83BeCt9cbvbojLyDIIvAJS
# lt/CmIjBIXQR2MZM6rEhTLiNtMuuOBc8O2iyYkrCp9bcE4aLyUJcKveeYws42WFk
# iFItYRzQz4Qx9YLzuQ7ye4eJ+0dLqemhJ6kDhzvicHW92Sl+EEbOCbCH4+xG/61H
# C+K7PuqVNHdMHQMvAU9/65RQ9vghZpsql7YrnHi6x5Ty6GBdluEQEBNJLKyS+GgV
# xOZn6qkjJqAkQifkxVqqDJt/UmmgZ1EUlLkBk/mhTcGlAgMBAAGjggOdMIIDmTA7
# BgkrBgEEAYI3FQcELjAsBiQrBgEEAYI3FQiC/ZwchKTnYYWZG4TY0AqDwfE/SYOr
# qFLJziwCAWQCAQgwEwYDVR0lBAwwCgYIKwYBBQUHAwMwCwYDVR0PBAQDAgeAMFMG
# A1UdIARMMEowSAYOKwYBBAGBwmYBZAoBAQAwNjA0BggrBgEFBQcCARYoaHR0cDov
# L3BraS5JU0NHLnBsL3JlcG96eXRvcml1bS9jcHMuaHRtbDAbBgkrBgEEAYI3FQoE
# DjAMMAoGCCsGAQUFBwMDMB0GA1UdDgQWBBRPF8aArwjUb++/ataeKOCF9Anh4zAm
# BgNVHREEHzAdgRtzdGFuaXNsYXcud2F3c3pjemFrQGlzY2cucGwwHwYDVR0jBBgw
# FoAU8erGz1jT5WzgIPGWD4EiCL3hQ2EwggEkBgNVHR8EggEbMIIBFzCCAROgggEP
# oIIBC4aBxGxkYXA6Ly8vQ049SVNDRyUyMEludGVybmFsJTIwSXNzdWluZyUyMENB
# LENOPXNydmNhMDEsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO
# PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9aXNjZyxEQz1sb2NhbD9jZXJ0
# aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJp
# YnV0aW9uUG9pbnSGQmh0dHA6Ly9wa2kuaXNjZy5wbC9yZXBvenl0b3JpdW0vSVND
# RyUyMEludGVybmFsJTIwSXNzdWluZyUyMENBLmNybDCCATQGCCsGAQUFBwEBBIIB
# JjCCASIwgbwGCCsGAQUFBzAChoGvbGRhcDovLy9DTj1JU0NHJTIwSW50ZXJuYWwl
# MjBJc3N1aW5nJTIwQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2Vz
# LENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9aXNjZyxEQz1sb2NhbD9j
# QUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhv
# cml0eTBhBggrBgEFBQcwAoZVaHR0cDovL3BraS5pc2NnLnBsL3JlcG96eXRvcml1
# bS9zcnZjYTAxLmlzY2cubG9jYWxfSVNDRyUyMEludGVybmFsJTIwSXNzdWluZyUy
# MENBLmNydDANBgkqhkiG9w0BAQUFAAOCAQEAWfmfe+iFomtQM6l58HYl/HQ08gSm
# qb93+8TUxDYG+UdCkliq/cYBUIkvhOTTpX2teblLeZ3mUbQP/Zc8vmbDt6t/wmg3
# D3N4yVkq5lBSz8SfMa0xy6651l3DGCYTZFOp4mEM998DaE0I0ufpDVW2Y1OZgmbq
# SwtbPBpHY+oL+CLnNVFNy1px2SovARFf4UvL5g6zJatJCajRZIupDfYfZqv4TK7N
# 3iGu9nG0O5YDGzIwoyRKle0bSXFIJGtqSXIrpXvc/2rg/8Q/G4z+Tv7PXY+eqvgR
# UQruaI6rzzpkLEtzwF6ZIJH5Vm3Vc4+BJF7XEVYgF/gLqE8sVewLbmUYOTCCB8Iw
# ggWqoAMCAQICCmGAJFIAAAAAAAIwDQYJKoZIhvcNAQEFBQAwMzELMAkGA1UEBhMC
# UEwxDTALBgNVBAoTBElTQ0cxFTATBgNVBAMTDElTQ0cgUm9vdCBDQTAeFw0wODEw
# MzExMzEwMjBaFw0xMzEwMzExMzIwMjBaMD8xCzAJBgNVBAYTAlBMMQ0wCwYDVQQK
# EwRJU0NHMSEwHwYDVQQDExhJU0NHIEludGVybmFsIElzc3VpbmcgQ0EwggEiMA0G
# CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDJms/OcjsUas9SCGTapl4RVfmgmlqY
# HdvM2tW9zzDqWrGoyWO3B6phlNM5LEBXraBR+7HVO8NZ7KPlh4CC7FUqPRF5nnez
# /eLmr0TfBEIVfZ2cmAyFn5+xhOS0Vm6CQEGSubWH6jVyUK4Ppj02QNBZppUmpe6z
# XlL0r4qWRw7E9vVEYZx1GS8JZ+xpGwK97X/wK6p9Fzf87SpVtdEUQ1mVP1aOBo8+
# 0zpjO9KfCqZwKQOtwBM6TczKMwNcTe/McUs1F2A+3VfDqCKhhcxQn9x4A+8pZSC0
# aKb+lvDEm2qwqoi71/sTFEkxRbuqtRmY4TJdyACLL25HM1F89KXCq1LFAgMBAAGj
# ggPKMIIDxjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTx6sbPWNPlbOAg8ZYP
# gSIIveFDYTALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMCAQAwggEcBgNVHSAE
# ggETMIIBDzCCAQsGDSsGAQQBgcJmAQEBAQAwgfkwgcAGCCsGAQUFBwICMIGzHoGw
# AEMAZQByAHQAeQBmAGkAawBhAHQAIAB3AHkAcwB0AGEAdwBpAG8AbgB5ACAAegBn
# AG8AZABuAGkAZQAgAHoAIABkAG8AawB1AG0AZQBuAHQAZQBtACAASQBTAEMARwAt
# AFAASwBJAC0ASwBvAGQAZQBrAHMAXwBQAG8AcwB0AGUAcABvAHcAYQBuAGkAYQBf
# AEMAZQByAHQAeQBmAGkAawBhAGMAeQBqAG4AZQBnAG8wNAYIKwYBBQUHAgEWKGh0
# dHA6Ly9wa2kuaXNjZy5wbC9yZXBvenl0b3JpdW0vY3BzLmh0bWwwGQYJKwYBBAGC
# NxQCBAweCgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAUdSlIg4Efvoizxm718egjFh4P
# FDAwggEFBgNVHR8Egf0wgfowgfeggfSggfGGNGh0dHA6Ly9wa2kuaXNjZy5wbC9y
# ZXBvenl0b3JpdW0vSVNDRyUyMFJvb3QlMjBDQS5jcmyGgbhsZGFwOi8vL0NOPUlT
# Q0clMjBSb290JTIwQ0EsQ049U1JWQ0FSb290LENOPUNEUCxDTj1QdWJsaWMlMjBL
# ZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWlz
# Y2csREM9bG9jYWw/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVj
# dENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MIIBDgYIKwYBBQUHAQEEggEAMIH9
# MEoGCCsGAQUFBzAChj5odHRwOi8vcGtpLmlzY2cucGwvcmVwb3p5dG9yaXVtL1NS
# VkNBUm9vdF9JU0NHJTIwUm9vdCUyMENBLmNydDCBrgYIKwYBBQUHMAKGgaFsZGFw
# Oi8vL0NOPUlTQ0clMjBSb290JTIwQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUy
# MFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9aXNjZyxE
# Qz1sb2NhbD9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNh
# dGlvbkF1dGhvcml0eTANBgkqhkiG9w0BAQUFAAOCAgEAn2sZajNae2DxDDaDDrSd
# RzWVRiD/KkzKDuBFwTOy3oi0QRFRqEYvr8t9mO3siaMBDZ9ThiEQlWWMnmZdlKf0
# btvcQ2G9/+Y2rvEWaTxEQgJ8yEcULgLMXu+WItAUS1uzkC+flbztM4i1patbMrhn
# P9Bt+nWF+gx1ibQ0bBd8MyQmZyX3CQYdqISmN+HcoD7R90qMkW/M2xxr0Mujuqmz
# l+6DMU0Bnlp+Ga9rdOvyNfH4ukCB2/8Sh7UHIF1OBgwVFjYw2eicHdL5yzjn7zr9
# 81z616m9e7AVgTcMlABtaoMHJ2Ou+SNFSKA3gTIUOpSK6bW4ZWUc8r5yp7I18WXN
# U79UYyvpPMrqPQD7LUqCaU6HhQj+BSc4Zr1eGsR1+mKCSxH68C/mNBtaOzvOXj2R
# yOiqttpoes2NPjF1EwuOwALbFZtITVfK56tfWYa+yPJAbl+/9VTqQwCQxjl1F6Yv
# fo9+XtSwziArAPjym0pzxEz1IuDh0tVrNAaP2GJJUOAz1FnU1DqDPM8DIfToP+T7
# HQqTWDCvVtoR6oRpuRwDdzOhNpK1vh6hW40DeyWx6Vbto/ZcxMCT7Ha7Q8pbhkR6
# +FONhFoFVNfot3pVLIm9WvKDYs/SrTmHREiMu/e0EnEjHdnHQnjmFpx5fmHxtzMe
# fuao/NyAiWIhEx/Sl93r40AxggHuMIIB6gIBATBNMD8xCzAJBgNVBAYTAlBMMQ0w
# CwYDVQQKEwRJU0NHMSEwHwYDVQQDExhJU0NHIEludGVybmFsIElzc3VpbmcgQ0EC
# Ck5ZpgcAAAAAATAwCQYFKw4DAhoFAKB4MBgGCisGAQQBgjcCAQwxCjAIoAKAAKEC
# gAAwGQYJKoZIhvcNAQkDMQwGCisGAQQBgjcCAQQwHAYKKwYBBAGCNwIBCzEOMAwG
# CisGAQQBgjcCARUwIwYJKoZIhvcNAQkEMRYEFPQFQ/K5T8jFSv0vdTZtYSCaSjJV
# MA0GCSqGSIb3DQEBAQUABIIBALhjXgtW8iff4/YeKkm+Ko9XZ82MdKr1a1COFQb4
# 08gf/BuQ7r141Qh/c4IDyZcd/apXkEPx0jmwLvx5/J3vRNdSV3BuR9wNyvnLcEuu
# INkLQPsVY+j1b7jF7QVnSH/yZ/0sG7jIJ/6SoeYChtK/SzwYFnUxtfsP6NgYE8EB
# E5XX/RAhkMHRd/czBRZgcqNsCTjtrYg6WS7dUKGdfSCBzzTGrZDig2tw18Tzle4B
# ffcnBMyH/eDi8ljcev05VDFY9GPR92rw2a2JqtX+GhWMzaRhLdbJswstYANTRsdh
# Il80Q2w7BB8p07cgq74PfsX88eT8Kf2plhJJ/MAJrEAEkWM=
# SIG # End signature block

A we właściwościach pliku ukazuje się dodatkowa zakładka Podpisy Cyfrowe, gdzie możemy obejrzeć interpretację systemową naszej pracy 🙂

Mam nadzieję, że przekonałem Was, iż korzystanie z bezpieczeńswa jest naprawdę proste 🙂