Mevcut bir zamanlanmış görevin tekrarlama sıklığını değiştirmek

Bir zamanlanmış görevim var. Her 5 dakikada bir çalışıyor. Powershell kullanarak bunun süresini değiştirmek istiyorum. İsmini kullanarak görev nesnesini bir değişkene atıyorum.

$gorev = Get-ScheduledTask -TaskName "Temizlik"

Bu görevin birden fazla tetiklemesi olabilir. Mevcut durumu görelim:

$gorev.Triggers

Triggers dizisinin içindeki 1 numaralı tetiklemenin tekrarlama sıklığını görelim:

$gorev.Triggers[1].Repetition.Interval

PT5M

Bu dönen değer ISO 8601 standardına göre bir süre ifadesi:

P: Periyot

T: Time (zaman)

M: Zaman ifadesi olduğu için 1 dakika (Minute)

P1M olsaydı 1 ay (Month) olacaktı. P1M2DT3M gibi bir ifade de 1 ay 2 gün 3 saat yapar. Windows görev zamanlayıcısı bu ifadelerin tümünü desteklemiyor. Basit ifadeler kullanmak lazım.

Bu 5 dakikayı 1 dakika olarak değiştirmek istiyorum. Önce $gorev nesnesini değiştirelim.

$gorev.Triggers[1].Repetition.Interval = "PT1M"

Bu nesne henüz sadece RAM'de. Bunu bir de görev zamanlayıcı nesnesi olarak yazalım.

Set-TaskScheduler -InputObject $gorev

Sonrasında bir de kontrol edelim, uygulanmış mı:

(Get-TaskScheduler -TaskName "Temizlik").Triggers[1].Repetition.Interval

PT1M 

Olduğunu görmek güzel. 

SPF kaydı inceleme

SMTP protokolünün istenmeyen mesajlara karşı hiçbir savunmasının olmamasından dolayı SPF (sender policy framework) denen bir koruma mekanizması var. Her alan adı, yetkilendirdiği "eposta gönderebilen IP adreslerini" belirtmeli. Bunu yapmak üzere seçilen yöntem, DNS sunucuya bir TXT kaydı oluşturmak.

Bu kayıt

v=spf1

ile başlamalı. Bu, yürürlükteki SPF sürümünü gösteriyor; henüz sürüm 1.

İkinci olarak eposta göndermekle yetkili sunucumuzun IP adresi olmalı. Bunu IPv4 veya IPv6 öneki ile belirtebiliriz. Örneğin

ip4:144.178.36.0/24

veya

ip6:2a01:b747:3001:200::/56

gibi. Tek bir IP veya CIDR notasyonu ile bir subnet olabilir. Ama bu eposta gönderme işini Google veya Microsoft gibi bir firmanın sunduğu hizmetler ile yapıyorsak bu iş için onların SPF kaydını bizim kaydımıza dahil edebiliriz.

include:_spf.google.com 

Son aşamada da bizim yetkilendirdiğimiz IP adresleri veya dış hizmetlerin dışında gönderilmiş tüm eposta mesajlarına ne yapılması gerektiği ile ilgili önerimizi belirtebiliriz. Bu sadece öneri. Herkesin uyacağı kesin bir kural değil. Olası seçenekler şunlar

-all    # Fail: Geri kalan mesajların hepsi geçersizdir

~all    # Soft fail: Hepsi geçersiz olabilir, alıcı karar versin

?all    # Neutral: Bu konuda bir davranış belirlenmemiş

+all    # Pass: Hepsi geçerli olsun 

Bugün geçerli olan bir örnek vereyim. 57.103.88.43 adresinden gelen ve isim@icloud.com gibi bir gönderen adresine sahip mesaj acaba gerçekten Apple sunucularından mı gönderilmiştir? Önce icloud.com alan adına ait SPF kaydını sorgulayalım. Ben isim çözümlemeleri için CloudFlare'in 1.1.1.1 DNS sunucusunu kullandım ama belirtilmesi zorunlu değil, başka geçerli/güvenilir bir sunucu da kullanılabilir.

Resolve-DnsName -Name icloud.com -Type TXT -Server 1.1.1.1

Bu cmdlet şöyle bir çıktı üretti:

Name               Type   TTL   Section    Strings
----               ----   ---   -------    -------
icloud.com         TXT    3207  Answer     {google-site-verification=Ik3jMkCjHnUgyIo
                                           FR0Kw74srr0H5ynFmUk8fyY1uBck}
icloud.com         TXT    3207  Answer     {google-site-verification=knAEOH4QxR29I4g
                                           jRkpkvmUmP2AA7WrDk8Kq0wu9g9o}
icloud.com         TXT    3207  Answer     {yahoo-verification-key=Ga0ZBHHIemhhe2EkR
                                           77Byx+IKXuf2Ezi90h0e6draoQ=}
icloud.com         TXT    3207  Answer     {google-site-verification=Gc0Hl3EIrWDLXgi
                                           svPdkUCAEwNs0gg5JHtd2pZD3J04}
icloud.com         TXT    3207  Answer     {v=spf1 redirect=_spf.icloud.com}

Bir alan adının birden fazla TXT kaydı olabilir ama sadece bir tane SPF kaydı olabilir. Birden fazla SPF kaydı geçerli değil. Burada bizim ilgilendiğimiz en alttaki v=spf1 ile başlayan satır.

v=spf1 redirect=_spf.icloud.com

redirect de include gibi, ama kararı da tamamen yönlendirdiği alan adının kararına bırakıyor. include ile -all gibi bir seçim belirtmek mümkünken, redirect ile değil. Bu durumda Yapmamız gereken _spf.icloud.com için SPF kaydını bir daha sorgulamak.

Resolve-DnsName -Name _spf.icloud.com -Type TXT -Server 1.1.1.1

Bu da şöyle bir çıktı verdi:

v=spf1 include:_nets2.icloud.com include:_nets1.icloud.com include:_nets0.icloud.com ~all

Matruşka bebek gibi. Sıra

_nets0.icloud.com

_nets1.icloud.com

_nets2.icloud.com

URL'leri için SPF sogrusu yapmaya geldi. Sırasıyla bunları da yapınca aşağıdaki gibi bir sonuç elde ettim:

_nets0.icloud.com
    17.41.0.0/16
    17.58.0.0/16
    17.142.0.0/15
    17.57.155.0/24
    17.57.156.0/24

_nets1.icloud.com
    144.178.36.0/24
    144.178.38.0/24
    112.19.199.64/29
    112.19.242.64/29
    222.73.195.64/29
    157.255.1.64/29
    106.39.212.64/29
    123.126.78.64/29
    183.240.219.64/29
    39.156.163.64/29

_nets2.icloud.com
    57.103.64.0/18
    2a01:b747:3000:200::/56
    2a01:b747:3001:200::/56
    2a01:b747:3002:200::/56
    2a01:b747:3003:200::/56
    2a01:b747:3004:200::/56
    2a01:b747:3005:200::/56
    2a01:b747:3006:200::/56
    2a01:b747:3007::/56

Bana mesajı gönderen IP adresi 57.103.88.43 bu listede, _nets2 sorgusunun ilk satırında var. 57.103.64.0/18 subnet'inin sınırları:

57.103.64.1 - 57.103.127.254

arasında. Sonuç: gönderen IP adresi yetkilendirilmiş.

Powershell, regex ve capture groups

Şöyle bir dosyam var, adı dosya.txt:

12.09.2014 Cihan  1993
01.10.2017 Zeynep 1992
02.05.2013 Mutlu  1991

Başlık satırı yok, virgülle ayrılmış değil, sabit uzunluklu.

Yeni öğrendiğim bir yöntem ile bu dosyayı okumak istedim:

gc dosya.txt | % {
    $a,$b,$c=$_ -split '(.{10}) (.{6}) (.{4})'
    [PSCustomObject]@{
        Tarih=$a
        Isim=$b
        Yil=$c
    }
}

Ama bu, beklediğim sonucu üretmedi. Burada

(.{10})    : 10 karakter uzunluğunda sabit genişlikli bir alan olarak tarih verisini, 

(.{6})    : 6 karakter uzunluğunda sabit genişlikli bir alan olarak isim verisini, 

(.{4})    : 4 karakter uzunluğunda sabit genişlikli bir alan olarak yil verisini

bulacak capture group'lar. Yukarıdaki ayrıştırıcı ile elde ettiğim sonuç aşağıdaki gibiydi:

Tarih Isim       Yil
----- ----       ---
      12.09.2014 {Cihan , 1993, }
      01.10.2017 {Zeynep, 1992, }
      02.05.2013 {Mutlu , 1991, }

Evet, tarih alanı boş ve tüm sütunlar kaymış. Hatta yıl sütunundan sonra virgülle ayrılmış bir boş alan daha var. Ben bunu şu şekilde çözmüştüm:

Get-Content veriler.txt | % {
    $a0,$a,$b,$c,$1=($_ -split '(.{10}) (.{6}) (.{4})')
    [PSCustomObject]@{
        Tarih=$a
        Isim=$b
        Yil=$c
    }
}

Yani burada $a0 ve $a1 değişkenlerini hiç hesaba dahil etmedim. Sonuç istediğim gibi oldu:

Tarih      Isim   Yil
-----      ----   ---
12.09.2014 Cihan  1993
01.10.2017 Zeynep 1992
02.05.2013 Mutlu  1991

Ama kod içime sinmedi. Neden gereksiz değişkenler kullanmak zorunda kaldım? Her bilişimcinin yapacağı gibi konuyu ayrıntılı olarak arama motorlarında aratmak yerine, Claude'a sordum. Cevabı şöyle:

Normal -split davranışı: Deseni bir "ayırıcı" (delimiter) olarak kullanır, ayırıcıyı bulur, ayırıcıyı atar ve geriye kalan parçaları döndürür.

Capture group'lu -split davranışı: Deseni yine ayırıcı olarak kullanır, ama bu sefer ayırıcıyı atmaz — parantez içindeki her bir capture group'un eşleştiği metni de sonuç dizisine ekler. Yani split hem "ayırıcının dışında kalan kısımları" hem de "ayırıcının içindeki (parantezlenmiş) kısımları" döndürür.

Bana çözüm önerileri olarak da şunları verdi:

1. Boş elemanları where-object ile süzmek

gc dosya.txt | % {
    $a,$b,$c=($_ -split '(.{10}) (.{6}) (.{4})') | Where-Object { $_ -ne "" }
    [PSCustomObject]@{
        Tarih=$a
        Isim=$b
        Yil=$c
    }
}

2. -split yerine -match kullanmak

gc dosya.txt | % {
    if ($_ -match '^(.{10}) (.{6}) (.{4})$') {
    [PSCustomObject]@{
        Tarih=$Matches[1]
        Isim=$Matches[2].Trim()
        Yil=$Matches[3]
    }
}

Powershell, ilginç bir kullanım

Kirk Munro'nun şu videosunda anlattığı birşey çok ilginç geldi. Powershell'in böyle bir kullanımı olduğunu bilmiyordum. Zaten videonun da amacı bu; bilmediğimiz kullanımları göstermek.

Örnek bir metin dosyamız olsun, D:\dosya.txt gibi. Düz virgülle ayrılmış veri. Ama başlığı yok.

İstanbul,34,Marmara
Ankara,06,İç Anadolu
İzmir,34,Ege
Bursa,16,Marmara

Bu verileri, elbette

$veri = Import-CSV D:\dosya.txt -Header "Sehir","Plaka","Bolge"

gibi bir yolla okuyabiliriz. Ama ilginç bir yöntem olarak

$veri = gc D:\dosya.txt | % {$sehir, $plaka, $bolge = $_ -split ","; [PSCustomObject]@{Sehir=$sehir;Plaka=$plaka;Bolge=$bolge}}

gibi bir ifade ile de okuyabiliriz. Elbette, düz virgülle ayrılmış dosyanın okunması için ilk yöntem çok daha yerinde ama ikinci yöntemde 

$sehir, $plaka, $bolge = $_ -split ","

gibi bir atama ve buradan elde edilen verilerin yapılandırılmış olarak

$veri = ... [PSCustomObject]@{
    Sehir=$sehir
    Plaka=$plaka
    Bolge=$bolge
}

atanması bana çok şık geldi.

Bilgisayarın bir dönemde ne kadar açık kaldığını bulmak

Örneğin son 30 günde bilgisayar ne kadar açık kalmış bulmak istiyorum. Microsoft tarafında bilgisayarın ne zaman açılıp ne zaman kapandığı konusu biraz karışık.

Eskiden sistem olay günlüğünde evenglog kaynağının 6005 ve 6006 olayları vardı, eventlog hizmetinin durup başlamasını kaydeden. Ama bu hizmetin durumunu takip etmek süper güvenilir bir yöntem değil.

İkinci yöntem Kernel-General kaynağının 12 ve 13 olayları olabilir. Bunlar daha güvenilir.

Ancak son dönemde hayatımıza giren fast boot (hızlı başlat) sonucunda, bilgisayar kapatılırken ne 6006 ne de 13 olay kaydının tutulmaması konuyu zor bir noktaya taşıdı. Bilgisayar artık kapanmıyor, bir çeşit uyku durumuna giriyor. Bunun sonucunda da Power-Troubleshooter kaynağından 1 olayını uyanma, Kernel-Power kaynağından 42 olayını da uykuya geçiş olarak düşünebiliriz.

Bitti mi? Hayır. Beklenmeyen bir kapanma olduğunda (elektrik kesintisi, mavi ekran vs) bilgisayar (elbette kapanırken bir kayıt düşmediği için) bir sonraki açılışta yaklaşık kapanmanın gerçekleştiği saate dair bir eventlog kaynağından 6008 olayı düşülüyor. Bununla birlikte Kernel-Power kaynağından 41 olayı da düşülüyor.

Özetle

açılma olayları:
    Power-Troubleshooter       1
    Eventlog                6005
    Kernel-General            12
 

kapanma olayları:
    Kernel-General            13
    Eventlog                6006
    Eventlog                6008
    Kernel-Power             107
    Kernel-Power              42

Ayıklamayı tamamladıktan sonra bu olayların arasındaki zaman farkını hesaplayarak toplamı bulmak lazım. Ama konu, özellikle 6008 olayı gibi sebeplerle biraz karışık.

eventlog 6008 olayındaki beklenmedik karakter

Sistem olay günlüğünde eventlog kaynağından 6008 olayında şöyle bir kayıt düşülüyor:

"17:59:44, ‎24.‎07.‎2026 tarihinde gerçekleşen önceki sistem kapanışı beklenmiyordu."

Bu olay,  bilgisayarın "17:59:44, ‎24.‎07.‎2026" tarihinde beklenmedik bir şekilde kapanmasının ardından bilgisayar ilk kez açıldığında (kim bilir ne zaman) düşüldüğü için bu olayın TimeCreated alanı ile açıklama içinde geçen saat ve tarih bilgisinin birbiri ile hiç ilgisi yok.

Olayın açıklamasında geçen alanlara, şöyle erişebilirim:

$ev1 = Get-WinEvent -Filterhashtable @{Logname="System";ProviderName="eventlog";Id=6008} -Max 1
$tarih = $ev1.Properties[1].Value
$saat = $ev1.Properties[0].Value

ve bunu bir tarih nesnesine çevirmek için

Get-Date -Date "$saat $tarih"

gibi bir yöntem kullanabilirdim. Ama kullanamıyorum. Çünkü, tarih verisinin önünde yazılmayan özel bir karakter var, 0x200e. Nasıl bulunabilir:

"{0:X}" -f [int][char]$tarih[0]
200E 

Bu karakter, görüntülemenin soldan sağa yapılmasını sağlıyor. Zaten bir soldan sağa görüntülüyoruz. Ama sağdan sola yazılan bir dilde tarih verisinin ters olarak görüntülenmemesi için sanıyorum böyle bir düzenleme yapmışlar. Bu alandan kurtulmak lazım.

$tarih =  $ev1.Properties[1].Value -replace([char]0x200e,'')

Get-Date -Date "$saat $tarih"

yeterli.

Windows bilgisayarlar için kimlik numarası (GDID)

Kullandığınız işletim sisteminin her hareketinizi takip edebildiği, sizi girdiğiniz her web sitesinde takip ettiğini bilseydiniz hala o işletim sistemini kullanabilir miydiniz?

Şu videoda söylenene göre her Windows bilgisayarın benzersiz bir kimlik numarası (GDID) var ve Microsoft, bir suçluyu bu kimlik numarasını takip ederek bulabildi. Bilgisayarınızın kimlik numarasının bir kopyası her ne kadar kayıt defterinde saklanıyor olsa da bunu silmemizin birşey değiştirmeyece söylenmiş. Ama neymiş diye merak ederseniz:

(gp "HKCU:\Software\Microsoft\IdentityCRL\ExtendedProperties").LID

Bunun benzeri bir durum Android için de olmuştu. Mahkemeye yansıyan bir anlaşmazlık, Google'ın konum bilgilerini adli makamlara vermesi sonucunda çözülebilmişti.

GDID konusunu Linus da işlemiş ve konuyu şöyle özetlemiş; GDID işletim sisteminin yeniden kurulması sonrasında aynı kalmıyor. Ancak çevrim içi bir hesap ile sisteme girip yapılması durumunda bütün gizem (!) çözülüyor.

Linux'ta zaman

Bilgisayarlar kapalıyken bile tarih ve saat kaydını tutabilir. Bunu anakartın üzerinde bu işten sorumlu bir zamanlayıcı çip ile yaparlar. Linux dünyası bunu RTC (real time clock) olarak adlandırır. Bu yazıda zamanı tutulması ile bu çipte tutulan zaman bilgisinden bahsedilecektir.

Varsayılan olarak Linux zamanı UTC olarak tutar. Sistem yerelleştirmesi (daha doğrusu zaman dilimi ayarlaması) nasıl ayarlanmışsa bu zamanın üzerine eklenir veya çıkartılır. Örneğin Türkiye +3 zaman diliminde olduğu için UTC olarak tutulan zaman 3 saat ilave edilir.

Ama bunun istisnası da var. Linux'a zamanı yerel saat diliminde tut diyebiliyoruz. Öncelikle mevcut durumu kontrol edelim.

timedatectl

komutunun çıktıları arasında "RTC in local TZ" geçen satıra bakmalıyız. Bende bu

RTC in local TZ: yes

olduğu için benim sistemim demek ki saati yerel saat dilimine göre saklıyor. Bunu değiştirmek için timedatectl komutu ile birlikte set-local-rtc kullanabiliriz. Örneğin UTC zaman dilminde saklayan varsayılan kurulumda durumu yerel saat dilimine çevirmek için

timedatectl set-local-rtc true

diyebiilir, ya da tekrar UTC'ye çevirmek için

timedatectl set-local-rtc false

diyebiliriz. Ya da Windows'da saat bilgisini UTC olarak tutmak için aşağıdaki kayıt defteri değişikliği yapılabilir.

"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation"
          RealTimeIsUniversal = DWORD(1) 

Durum kontrolü için

(gp  "HKLM:\SYSTEM\CurrentControlSet\Control\TimeZoneInformation" "RealTimeIsUniversal").RealTimeIsUniversal

Zamanı yerel saat diliminde saklayan sistemimde

journalctl -b

komutu ile ilk kaydedilen olayın saatini incelediğimde garip bir şekilde mevcut saat dilimimde değil, bundan da 3 saat ötesinde bir saat görüyorum. Örneğin 13:19'da açtığım bilgisayarım için jounralctl'in ilk satırlarında 13:19 değil, 16:19 görüyorum. Bunun sebebi, ilk açılışta sistemi başlatan initramfs sisteminin sistemin RTC (real time clock) ile tutulan sistem zamanına +3 (Türkiye Saati) ilave ederek başlaması. Ancak bu bir yerde düzeliyor. İlk satırlar, kernel modülünün kayıtları:

Ağu 02 16:19:00 fedora3 kernel: Linux version 7.1.5-101.fc43.x86_64 (mockbuild@3a3dadcda8bc47f1a8cfdc1237822e70) (gcc (GCC) 15.3.1 202607>

Bir süre sonra initramfs işlevi sonlanıyor ve root filesystem'e geçiş yapılıyor. Bu noktadan sonra zaman hızlı bir şekilde 13:19'a  geçiş yapıyor.

Ağu 02 16:19:03 fedora3 systemd[1]: Starting initrd-switch-root.service - Switch Root...
Ağu 02 16:19:03 fedora3 systemd[1]: Switching root.
Ağu 02 16:19:03 fedora3 systemd-journald[260]: Journal stopped
Ağu 02 13:19:04 fedora3 systemd-journald[260]: Received SIGTERM from PID 1 (systemd).

last reboot komutu ile bakılınca görülen saat beklenen, yerel Türkiye saati 13:19:

last reboot -n 1

reboot   system boot  7.1.5-101.fc43.* Sun Aug  2 13:19   still running 

Windows tarafında benzer bir zaman değişikliği olmuyor, en azından yerel zaman dilimi olarak.

Bir Windows işletim sisteminin açılış kimliği (Boot Id)

Linux'ta

journalctl --list-boots

komutu ile her bir açılışa bir açılış numarası verilir. 0 numaraya sahip açılış mevcut açılıştır, -1 bir önceki, -2 numara iki önceki şeklinde gider.

Window'da da buna benzer bir açılış numaralarının olduğunu öğrendim. Ama Windows'daki açılış kimlikleri 0'dan başlayıp sürekli artan bir düzende gidiyor. Ama bu sayılara garip bir şekilde sadece Kernel-Boot olay kayıtlarından erişebildim.

Get-WinEvent -FilterHashtable @{LogName='System';ProviderName='Microsoft-Windows-Kernel-Boot';Id=20} |

    Select-Object TimeCreated,

        @{N='LastShutdownGood';E={$_.Properties[0].Value}},

        @{N='LastBootGood';E={$_.Properties[1].Value}},

        @{N='BootId';E={$_.Properties[2].Value}}

Bu sorguda BootId ile dönen değerler aradığımız açılış kimlikleri. Sadece ne sonuncu değeri sorgulayarak bilgisayarın, en son işletim sistemi yüklenmesinden sonra toplam kaç kez açıldığını bulabiliriz. Sistem olay günlüğünün doluluğu ve boyutuna göre belli bir tarihten önceki açılışlara ait bilgilere ulaşamıyor olabiliriz ama en azından sürekli artan bir yapıda olması, bilgisayarın toplam kaç kez açıldığına dair sayıyı bozmuyor.

Adından da anlaşılabileceği gibi LastShutdownGood ve LastBootGood  alanları sırasıyla en son kapanma ve en son açılma işlemlerinin eksiksiz gerçekleşip gerçekleşmediğini gösterir.

Tarih verisi ve ayraçlar

Tarih nasıl yazılır, bu konuda bazı kafa karışıklıkları var. 12 Kasım 2025 tarihini ifade etmek için doğru ifade hangisi?

12.11.2025

12/11/2025

11/12/2025

2025-11-12

2025/11/12

Powershell'in Get-Date cmdlet'i yukarıdaki bütün ayraçları kabul ediyor. Ben de merak ettim, daha kaç farklı ayraç kabul edilebilir, hangi formatlar (en azından Powershell içinde) geçerlidir.

Tek tek denemek yerine olası ayraçların olduğu bir dizi oluşturdum. 

$ayraclar = ("",":",";",".",",","/","\","|","-","?","'","~","``","+","%","&","=","!")

Baz tarih değişkenimi de şöyle şekillendirdim:

$baz = "12A11A2025"

Burada sanal ayraç olarak "A" kullandım, çünkü sonrasında her seferinde A'ları ilgili ayraç karakteri ile değiştirmek istiyorum.

$ayraclar | % {try {$dongu=$baz.replace("A",$_);date $dongu -f d -ea stop;$sonuc="tamm";$renk="Green"} catch {$sonuc="hata";$renk="Red"} finally {Write-Host "$dongu - $_ - $sonuc" -for $renk}}

Daha okunabilir bir hali için

$ayraclar | ForEach-Object {

    try {

        $dongu=$baz.replace("A",$_);

        Get-Date $dongu -Format "d" -ErrorAction Stop;

        $sonuc="tamm";

        $renk="Green"

    }

    catch {

        $sonuc="hata";

        $renk="Red"

    }

    finally {

        Write-Host "$dongu - $_ - $sonuc" -ForegroundColor $renk

    }

}

Bunun sonucu şöyle oldu:

12112026 -  - hata

12:11:2026 - : - hata

12;11;2026 - ; - hata

12.11.2026

12.11.2026 - . - tamm

12.11.2026

12,11,2026 - , - tamm

12.11.2026

12/11/2026 - / - tamm

12\11\2026 - \ - hata

12|11|2026 - | - hata

12.11.2026

12-11-2026 - - - tamm

12?11?2026 - ? - hata

12'11'2026 - ' - hata

12~11~2026 - ~ - hata

12`11`2026 - ` - hata

12+11+2026 - + - hata

12%11%2026 - % - hata

12&11&2026 - & - hata

12=11=2026 - = - hata

12!11!2026 - ! - hata

Yeşil satırlar çalışan ayraçları gösteriyor: nokta (.), virgül (,), kesme (/) ve tire (-). Gri satırlar da Get-Date'in algıladığı tarihi (12.11.2025 yerine 11.12.2025 algılayıp algılamadığını) görmek için.

Piller, bataryalar ve aküler

Pil, kimyasal bazı süreçlerle enerji depolayan ve bu enerjiyi (neredeyse) sabit bir gerilim ile verebilen enerji depolama sistemleri. Batarya da aynı, akü de. İngilizce'de bütün hepsi batarya (pil) olarak adlandırılıyor.

Özellikle şarj edilebilen pillerle ilgileniyorum. Eskiden beri değişik pil teknolojileri vardı. Şu videoda denk geldiğim bilgiler hoşuma gittiği için not almak istedim. Videoda 4 pil teknolojisi incelenmiş:

NiMH: Nikel metal hidrit piller. Bunlardan da önce NiCd (nikel kadmiyum) piller vardı, çoktandır görmüyorum. Kadmiyum zehirli olduğu için sanıyorum artık kullanılmıyor. Onun yerine piyasaya sürülen bu pil teknolojisi, pile ihtiyaç duyan elektronik cihazları besleyen güvenilir bir teknoloji. Yerine geldikleri kalem pil olarak bildiğimiz AA veya AAA pillerin sağlayabildiği 1.5 V gerilimin yerine 1.2 V üretiyorlar. Ekolojik açıdan güvenli olarak nitelendiriliyorlar. Ama tam boşalmadan tekrar şarj edilirse kapasiteleri düşüyor. Kullanılmasa bile kendi kendine deşarj olabiliyorlar.

Li-Ion: Son dönemin popüler enerji kaynağı lityum iyon piller. Elektrikli araçları bile şu an için bu pil teknolojisi besliyor. Her bir hücre 3.6 V gerilim üretiyor. Çok güvenli değiller. Darbeler ve kısa devreler karşısında hassaslar. İçerden gelen bir yanmanın durdurulması zor oluyor.

Li-Po: Lityum polimer piller. Diğer iki teknolojinin sunduğu silindir şeklinde hücrelere kıyasla esnek polimerler sayesinde yassı bir yapıda olabiliyorlar. Bu sebeple cep telefonları gibi ince cihazları beslemeleri mümkün oluyor.

Lead-Acid: Kurşun asit piller. Fosil yakıtlarla çalışan arabaların, yine de vazgeçilmez şarj edilebilen enerji kaynakları. Bitince araba çalışmaz ama şarj edilebilir. Çok güvenliler, genellikle kazalar sonrasında bir soruna yol açmıyorlar, kısa devrelere karşı da görece dayanıklılar. Ama kurşun içermek gibi kötü bir özellikleri var.

Piller şarj edildikten sonra sabit bir akımla deşarj olurken belli bir süre bu akımı vermeye devam edebiliyor. Bu akım verme kapasitesini mAh (mili amper saat) olarak belirliyoruz. Her pilin de bir çıkış gerilimi var, 1.2 veya 3.6 gibi. Bu çıkış gerilimi ile mAh cinsinden kapasiteyi çarparak da Wh cinsinden toplam enerji kapasitesini buluyoruz.

Bahsettiğim kanal, pillerin hacimlerini ve ağırlıklarını hesaplayarak birim hacim ve birim ağırlık başına pillerin sağlayabildiği enerji miktarını hesaplamış. Bir birim enerjinin maliyetini dahil etmiş. Sonuçta aşağıdaki gibi bir tablo çıkmış.

Pil çeşidi	Wh/kg	Wh/L	Wh/$
NiMH	98,0	391,48	0,69
Li-Ion	209,3	544,14	1,38
LiPo	153,1	376,73	0,89
Kurşun-Asit	32,7	91,60	3,60

Buradan çıkan sonuçlar:

1. En uygun fiyat NiMH, arkasından LiPo, daha sonra Li-Ion
2. Gerek birim ağırlık gerekse birim hacim başına en fazla enerji Li-Ion pillerde
3. Araçlarda kullandığımız aküler en verimsiz, aynı zamanda en pahalı olanı ama en güvenlileri 

Alt öğelerin sahibini toplu değiştir

Bir klasörün altındaki tüm alt klasörler ve dosyaların NTFS dosya sistemindeki sahibini, üst klasörün sahibi ile değiştirmek istiyorum. Aşağıdaki gibi bir betik işe yaradı.

param(

    [Parameter(Mandatory=$true)][string]$Path

)

$acl = Get-Acl -Path $Path

$cevap = Read-Host "$Path ve altindaki dosya ve klasorlerin sahibini $($acl.Owner) olarak degistirelim mi? (e/H)"

if ($cevap -eq "e" -or $cevap -eq "E") {

    Get-ChildItem -Path $Path -Recurse | ForEach-Object {

        try {

            $item = $_

            $itemAcl = Get-Acl -Path $item.FullName -ErrorAction Stop

            $itemAcl.SetOwner([System.Security.Principal.NTAccount]$acl.Owner)

            Set-Acl -Path $item.FullName -AclObject $itemAcl -ErrorAction Stop

            Write-Host "Tamam " -ForegroundColor Green -NoNewline

            Write-Host $item.FullName

        }

        catch {

            Write-Host "Hata  " -ForegroundColor Red -NoNewline

            Write-Host $item.FullName

        }

    }

} else {

    Write-Host "Islem iptal edildi."

}