[megoldva] fájlok (sok) dátumának módosítása - relatívan, egy órával vissza

Hi,

Cím elmondja a lényeget:

"fájlok (sok) dátumának módosítása - relatívan, egy órával vissza"

Tehát:

- adott egy mappányi fájl, több almappában
- dátumuk korrekt, csak 1 kerek órával több, mint kéne (perc-másodperc pontos, meg is kell tartani)
- ezt kéne valahogy visszaállítani, akár command line batch, akár segédprogram (free) játszik

(probléma oka: archíválásnál linux rendszerre lett windows-ról másolva, majd vissza, és valahol nem jól landoltak a dátumok...most meg a szinkronizáló program hisztizik, mert a tartalom oké, de a dátumok nem)

Hozzászólások

Ha már a linuxon is rossz a dátum, akkor ott módosít, majd visszamásol, ha csak a windowson, akkor simán visszamásol. Szerintem.

félreértetted, a helyzet már "végleges", a másolás (és kiegészítés) már megtörtént, közel 70 GB adatról van szól, ergo nem kezdeném újra...jelenleg tesztelem épp, valószínűleg sikerült egy időzóna beállításon elcsúsznia a dolognak, amikor fatra került át az adat...de nem járható az újramásolás

Ez esetben, ha megoldható Linuxon a "helyreállítás", a következő segíthet:

find . -exec touch -d '1 hour ago' -r {} {} \;

Tehát végigmegy az aktuális könyvtárból kiindulva és az összes filet (ill. könyvtárat) átadja az általad leírt parancsnak.
Szerintem ezzel meg is van oldva a probléma. :)

Persze ez Linuxon.
Esetleg ha megoldható, hogy valamilyen módon Linux-féle környezet induljon a gépen (közvetlen, virtualizálva, cygwin), akkor ok... (ezt kétlem :)

Egyébként lehet, érdemes talán átnézni néhány "rename tool"-féle programot Windows alá, hátha van ilyen funkció valamelyikben.

Cask egy apró kérdés: szerinted a kérdezőt előbbre viszi a probléma megoldásában az, hogy te személy szerint linuxon hogyan oldanád meg?

(Ráadásul, ahogy lx kolléga rá is mutatott, nem is jó megoldás, mivel minden fájl idejéhez a 'current time-1' értéket állítja be.)

Jaja, én is benéztem, csak alább, a find-es résznél tűnt fel, hogy kétszer van a {}, és néztem, hogy milyen marhaság az már... aztán rájöttem, megnéztem feljebb, manpage, facepalm, javítás :)

(Ja, azon kevesek közé tartozom, akik átállították, és az új hozzászólások elöl jelennek meg, ezért van nekem "fordítva" :D)

Előre szólok: nem biztos, hogy elegendő a fájlok dátumainak módosítása. A fájlok dátumának tárolása ugyanis fájlrendszerenként eltérő pontosságú (lásd: http://msdn.microsoft.com/en-us/library/windows/desktop/ms724290(v=vs.8…).

FAT fájlrendszernél: 2 seconds for last modified time, 10 ms for creation time, 1 day for access date, 2 seconds for deletion time
NTFS-nél: 100 ns minden dátumra.

Vagyis elképzelhető, hogy az oda-vissza másolás következtében történhetett veszteség a pontosságban. Ezt majd tartsd észben akkor, ha az alábbi megoldásomat kipróbáltad, de a szinkronizáló program továbbra is hisztizik.

Én PowerShell-t használnék, mivel Windows alatt véleményem szerint ezzel lehet a leggyorsabban megoldani a problémát. Apropó, melyik dátumot szeretnéd módosítani: create/last access/last write?

Powershell szkript a fájl (és folder) dátumok módosítására:
$folder = "c:\temp"
$files = Get-ChildItem -Recurse $folder
foreach ($file in $files)
{
# Lehetseges tulajdonsag nevek: CreationTime, LastAccessTime, LastWriteTime
$file_date = $file.LastWriteTime

# Egy kis logolas soha sem art
Write-Host -NoNewline "valtoztatas: $file $file_date"
$file.LastWriteTime = $file_date.AddHours(-1)
Write-Host " - OK"
}

Használat: lemented file_time_changer.ps1 néven. Elindítod a PowerShell-t, majd belépsz abba a könyvtárba, amelyikben a szkript fut. Kiadod a .\file_time_changer.ps1 > file_date_changes.txt parancsot. Ha a PowerShell olyasmit ír, hogy "File C:\temp\file_time_changer.ps1 cannot be loaded because the execution of scripts is disabled on this system", akkor a PowerShell ablakba írd be: Set-ExecutionPolicy Unrestricted.

Tökéletes...viszont:

A fájloknak csak közel a fele érintett, ezért ránéztem manuálisan...és total commander-ben ugyan az a dátuma van a két oldalnak, minden fájlnak. Mit olvashat félre a sync program (GoodSync)?

NTFS és FAT a két fájlrendszer, a FAT-on tűnik az adott program számára minden egy órával korábbinak, total commander-el nézve egyenlőek.

szerk.:

Hozzászólások időbélyege hup-on lehetséges, hogy nem jó időzónában van? Nemrég írtam, és 8:xx-et ír. Szerintem én vagyok a pontos: http://www.pontosido.hu/ts/time1s.cgi

A FAT mindig lokális időként tárolja a fájl időpontokat, míg az NTFS mindig UTC-ben (forrás: az általam linkelt MSDN cikk: http://msdn.microsoft.com/en-us/library/windows/desktop/ms724290(v=vs.8…), valahol itt lehet a kutya elásva.

A HUP-on kézzel kell beállítanod a profilodban az időzónát.

Tudsz valamit javasolni, mint (fenntartható) megoldás? Az NTFS laptop belső hdd, és a külső FAT usb hdd között naponta többezer összehasonlítás fog futni...

Ha jól értem, akkor a sync programnak kéne intelligensen, ahogy a TCMD csinálja, értelmezni, hogy az FAT idő, tehát egy óra plusz illik a GMT alapján?

Talán tudok. Ha már windwos, akkor külső HDD-t csakis NTFS-re szoktam formázni, mivel az naplózó fájlrendszer. A te esetetben már csak azért is érdemes lenne átállni rá, hogy a két FS között a fájl idő felbontása egyező legyen.

A te esetedben nem tudom megállapítani, hogy melyik program a ludas (de valószínűleg a szinkronizáló). Még azt lehetne megnézni, hogy a command prompt ablakban (nem a PowerShell) a sima dir parancsra milyen dátumokat ad az NTFS, és a FAT oldalon.

cmd ellenőrizve, ugyan azokat a dátumokat adja, ezért gondolom a sync-et hibásnak, már support-nak írtam is (mivel én fordítottam a program kezelőfelületi szövegeit magyarra, jó a kapcsolat)

NTFS formázás: windows xp alatt tapasztalatod szerint mennyire biztonságos fat-ntfs convert-et csinálni?

(eredetileg kompatibilitási okok miatt maradtam a fat-nál, de közben rájöttem, hogy van ntfs driver linux-ra is, ami ahogy tudom, stabil)

Közben el kellett menjek, már nem tudtam megválaszolni.

Azt válaszoltam volna, hogy nincs (sok) tapasztalatom FS konverziónál, de mivel az áramszünet (vagy bármilyen egyéb okból) adatvesztésre van esély ezért a backup-format-restore változatot javasoltam volna. Örülök, hogy így is sikerült. Megtennéd, hogy a hozzászólásod témáját egy [megoldva] prefixszel látod el? Köszi. :)

#!/usr/bin/env python

import os

for dirname, dirnames, filenames in os.walk('.'):
--for subdirname in dirnames:
----fn = os.path.join(dirname, subdirname)
----st = os.stat(fn)
----os.utime(fn, (st[7]-3600, st[8]-3600))
--for filename in filenames:
----fn = os.path.join(dirname, filename)
----st = os.stat(fn)
----os.utime(fn, (st[7]-3600, st[8]-3600))

Sajnos a szóközt nem viszi át a portálmotor, így helyette a -- -okat cseréld ugyanennyi szóközre.
Windows-nak nem része a python, tehát ott ---> http://python.org/download/

De, a python szkriptekben használhatsz tabokat is, de csak konzisztensen.
A fenti szkriptben a -- karaktert kell egy tabra kicserélni, és úgy működik.

A szkriptből úgy tudod kihagyni a mappákat, ha a második forciklust (for subdirname in dirnames:) és annak belsejét kihagyod a szkriptből.

Aztán jött a Python és a nyelv szintaktikájával kierőszakolta azt, hogy a fejlesztők indentáljanak. Szerintem ez nem probléma, ettől olvashatóbb lesz a kód. Tudom persze, hogy normális fejlesztő a munkája során indentál, de a kezdők nem, őket legalább neveli ez.

Amit problémásnak tartok Pythonban, az a self kötelező használata. De ebből legyen itt ennyi elég, nem akarom szétoffolni a topicot.

tölsd le a GnuWin32 touch.exé-t, tudja uazt mint a GNU touch, aztán az adott könyvtárban:

FOR /R %f IN (*) DO @touch.exe -d "1 hour ago" -r %f %f

(space/magick karakterekkel a fájlnevekben nem tudom megmondani, mit csinál. quot-olhatod a %f-eket, az csökkenti az ilyes hibákat)

~~~~~~~~
http://www.youtube.com/watch?v=VbUVqODL1nE