Wygaś pliki w folderze: Usuń pliki po x dniach


12

Chcę utworzyć „folder upuszczania” na dysku współdzielonym z systemem Windows, który jest dostępny dla wszystkich. Chciałbym, aby pliki były automatycznie usuwane, jeśli znajdują się w folderze przez ponad X dni.

Wygląda jednak na to, że wszystkie metody, które znalazłem, wykorzystują datę ostatniej modyfikacji, czas ostatniego dostępu lub datę utworzenia pliku.

Próbuję zrobić z tego folder, w którym użytkownik może upuszczać pliki, aby udostępnić je komuś. Jeśli ktoś skopiuje lub przeniesie pliki tutaj, chciałbym, aby zegar zaczął odtąd odtąd. Jednak data ostatniej modyfikacji i data utworzenia pliku nie zostaną zaktualizowane, chyba że ktoś faktycznie zmodyfikuje plik. Czas ostatniego dostępu jest zbyt często aktualizowany ... wydaje się, że samo otwarcie katalogu w Eksploratorze Windows zaktualizuje czas ostatniego dostępu.

Czy ktoś wie na to rozwiązanie? Wydaje mi się, że codzienne katalogowanie skrótu plików, a następnie wygasanie plików na podstawie skrótów starszych niż określona data może być rozwiązaniem ... ale pobieranie skrótów plików może być czasochłonne.

Wszelkie pomysły będą mile widziane!

Uwaga: Przeglądałem
już tutaj sporo odpowiedzi ... zajrzałem do Monitora zasobów serwera plików, skryptów PowerShell, skryptów wsadowych itp. Nadal używają czasu ostatniego dostępu, czasu ostatniej modyfikacji lub czasu utworzenia ... które, jak opisano, nie odpowiadają powyższym potrzebom.


Jedno pytanie, jak wspomniał @Michael Kjorling, czy licznik czasu przestaje się liczyć, jeśli plik zostanie zmodyfikowany po upuszczeniu w polu?
Get-HomeByFiveOClock

To, czego szukasz, to odpowiednik systemu Windows tmpwatch.
Avery Payne

Odpowiedzi:


5

Użyliśmy kombinacji skryptu PowerShell i zasady. Zasada określa, że ​​użytkownik musi utworzyć folder w udziale Drop_Zone, a następnie skopiować dowolne pliki do tego folderu. Kiedy folder będzie miał 7 dni (używając CreationTime), skrypt PowerShell go usunie.

Dodałem również trochę logowania do skryptu PowerShell, abyśmy mogli zweryfikować jego działanie, i włączyłem kopie w tle, aby ocalić całkowicie nieudolne od siebie.

Oto skrypt bez wszystkich elementów logowania.

$location = Get-ChildItem \\foo.bar\Drop_Zone
$date = Get-Date
foreach ($item in $location) {
  # Check to see if this is the readme folder
  if($item.PsIsContainer -and $item.Name -ne '_ReadMe') {
    $itemAge = ((Get-Date) - $item.CreationTime).Days
    if($itemAge -gt 7) {
      Remove-Item $item.FullName -recurse -force
    }
  }
  else {
  # must be a file
  # you can check age and delete based on that or just delete regardless
  # because they didn't follow the policy
  }
}

1
Wydaje się to najprostsze, nie kręci się ze znacznikiem daty i godziny pliku, alternatywnymi strumieniami danych, ani nie wymaga listy plików i dat ich usunięcia. Zamierzałem stworzyć niesamowity scenariusz, który zawierał wszelkiego rodzaju magię, ale potem to zobaczyłem.
BeowulfNode42

i nie wymaga zdarzenia obserwującego system plików wywołującego cały czas skrypt, ponieważ można go uruchamiać raz dziennie, i nie ma znaczenia, czy dzień zostanie pominięty z jakiegokolwiek powodu.
BeowulfNode42

2
Świetny prosty pomysł, jak wskazał @ BeowulfNode42. Aby upewnić się, że użytkownicy muszą utworzyć folder, proste „Odmów” ACL „Utwórz pliki / Zapis danych” do „Tylko ten folder” zapewni, że użytkownicy również będą musieli utworzyć podfoldery.
Brett G

3

Jeśli możesz założyć NTFS, możesz zapisać klucz (Guid) w alternatywnym strumieniu pliku. Plus data, dzięki czemu można w zasadzie przechowywać bazę danych w plikach.

Więcej informacji można znaleźć na stronie

http://blogs.technet.com/b/askcore/archive/2013/03/24/alternate-data-streams-in-ntfs.aspx

Zasadniczo możesz przechowywać dodatkową zawartość w osobnym strumieniu, który jest kodowany specjalną nazwą.


Jak by to zrobić?
Brett G

@BrettG Dodano link do dokumentacji. „Alternatywny strumień danych NTFS” sprawiłby, że znajdziesz go również w google, na wszelki wypadek - nie znasz google.
TomTom

Przepraszam, wiem, jakie są alternatywne strumienie danych, starałem się po prostu zrozumieć ich użycie w tym kontekście. Mówisz więc, zamiast używać skrótu lub czegoś innego, użyj identyfikatora GUID (i / lub daty) w alternatywnym strumieniu danych, aby śledzić pliki. Aha.
Brett G

Tak. Jeśli możesz niezawodnie OZNAKOWAĆ plik - możesz nawet umieścić w nim datę oznaczenia - to nie musisz obliczać wartości skrótu.
TomTom

Tylko uważaj, czy plik jest kopiowany ze sklepu, edytowany, a następnie kopiowany z powrotem. Chcesz wtedy zrestartować stoper, dla którego użyteczny może być skrót.
CVn

2

Możesz użyć IO.FileSystemWatcher, który pozwala „oglądać” folder z nowymi plikami. Oto elementy, których potrzebujesz, aby to zadziałało.

Te zmienne konfigurują ścieżkę do oglądania i filtr do dostrajania plików do śledzenia:

$watchFolderPath = $env:USERPROFILE
$watchFolderFilter = "*.*"

Spowoduje to ustawienie parametrów folderu do obejrzenia i działań do wykonania po wystąpieniu zdarzenia. Zasadniczo resetuje LastWriteTime dla każdego pliku, gdy jest zapisany:

$watcher = New-Object IO.FileSystemWatcher $watchFolderPath, $watchFolderFilter -Property @{
    IncludeSubdirectories = $true
    NotifyFilter = [IO.NotifyFilters]'FileName, LastWrite'
    }
$onCreated = Register-ObjectEvent $watcher Created -SourceIdentifier FileCreated -Action {
    $FileName = $Event.SourceEventArgs.FullPath
    $file = Get-Item $FileName
    $file.LastWriteTime = Get-Date
    }

W razie potrzeby zdarzenie można wyrejestrować, używając:

Unregister-Event -SourceIdentifier FileCreated

Wreszcie możesz uruchomić to raz dziennie, aby wyczyścić stare pliki:

Get-ChildItem $watchFolderPath -Recurse | Where-Object {((Get-Date)-$_.LastWriteTime).TotalDays -gt 6} | Remove-Item

To powinno być wszystko, czego potrzebujesz ...


Edytowano to, aby ustawić atrybut LastWriteTime podczas tworzenia pliku, a następnie użyć go do późniejszego usunięcia plików.
Tim Ferrill

1

Minęło trochę czasu, ale stworzyłem stosunkowo prostą metodę rozwiązania tego problemu.

Dotykam dowolnych plików dodanych do katalogu upuszczania (monitorowanych za pomocą narzędzia do monitorowania zasobów) i ustawiam datę ostatniej modyfikacji na datę dodaną do folderu.

Mógłbym wtedy użyć daty ostatniej modyfikacji, aby usunąć wszystkie pliki, które muszą zostać unieważnione. Ma to również tę zaletę, że jeśli ktoś naprawdę zaktualizuje plik, zresetuje odliczanie.


Idealny pomysł. Zrobię własne badania ... ale masz pojęcie, jakiego narzędzia do monitorowania zasobów użyłeś?
Brett G

@BrettG szczerze mówiąc, było to prawie 10 lat temu. Nie pamiętam Sprawiasz, że czuję się stary. :) Gdybym miał to zrobić dzisiaj, wykonałbym zadanie oparte na zdarzeniach kontrolujących system plików w przeglądarce zdarzeń. Myślę, że obiekt FileSystemWatcher .NET jest dostępny za pośrednictwem PowerShell. To byłaby inna opcja.
Tim Brigham

Ha, nie zdawałem sobie sprawy, że masz na myśli tak długo, kiedy powiedziałeś „chwilę”. Tak zabawne, tylko patrzyłem na FileSystemWatcher. Chociaż nie sądzę, aby działało z przeniesionymi / skopiowanymi plikami. Dziękuję za odpowiedź!
Brett G

1
@BrettG - Fileystemwatcher może być używany w połączeniu z tabelą śledzenia, ale ma swoje własne problemy. Zobacz tutaj: stackoverflow.com/questions/1764809/… stackoverflow.com/questions/6000856/filesystemwatcher-issues
JohnP

1
@BrettG - To także dobre rozszerzenie do FSW: codeproject.com/Articles/58740/…
JohnP

1

Nie ma sposobu, aby polegać na datach, w których plik został skopiowany lub przeniesiony do folderu. Windowsowi udaje się zachować to w różnych systemach plików, dyskach, udziałach sieciowych itp. Możesz być w stanie wypracować coś z serwerem plików linux, lub uniemożliwić bezpośrednie kopiowanie plików za pomocą FTP lub internetowego systemu przesyłania.

Jeśli nie masz nic przeciwko, aby ludzie nie mogli modyfikować plików po ich przesłaniu, możesz mieć osobne foldery do przesyłania i dostępu oraz skrypt, który przenosi pliki między nimi i zmienia ich datę. Ale wygląda na to, że chcesz, aby ludzie mogli bezpośrednio modyfikować pliki.

Tak prostym, choć nieco hackerskim rozwiązaniem byłoby zepsuć daty. Napisałbym dwa skrypty:

Skrypt zmiany godzinowej daty

Skrypt powinien być uruchamiany co godzinę w preferowanym języku, który:

  • Wyszukuje dowolny plik ze zmienioną datą w ciągu ostatnich 20 lat.
  • Kiedy znajdzie taki plik, zmień jego datę modyfikacji na dziś minus 20 lat.

W PowerShellie wyglądałby mniej więcej tak:

$path = "D:\test"

$today = Get-Date
$before = $today.AddDays(-7300) #356*20 days

Get-ChildItem -Recurse -Path $path | foreach {
    if ($_.LastWriteTime -gt $before) {
        Write-Host $_.Name
        $_.LastWriteTime = $before
    }
}

Uruchomienie tego skryptu dzisiaj (27 maja) ustawia zmodyfikowaną datę wszystkich plików na 1 czerwca 1994 r. - dokładnie 356 * 20 dni temu. Ponieważ zmienia tylko pliki nowsze niż wartość $ before, nie będzie dotykać plików, które zostały już ustawione w przeszłości.

Skrypt oczyszczania

Skrypt czyszczenia będzie uruchamiany co noc i:

  • Wyszukaj pliki ze zmodyfikowaną datą „20 lat i X dni temu”
  • Usuń ich

Nie napiszę skryptu dla tej części - istnieje wiele narzędzi, które mogą obsłużyć usuwanie plików starszych niż określona data, wybierz cokolwiek chcesz. Ważną częścią jest poszukiwanie plików, które mają 7300 + X dni, gdzie X to liczba dni, w których chcesz je przechowywać od ostatniej modyfikacji.

Zalety

Ma to kilka zalet w porównaniu z innymi odpowiedziami tutaj:

  • Timer zostanie zresetowany, jeśli ktoś zmodyfikuje plik.
  • Nie ma potrzeby oznaczania plików przez alternatywne strumienie NTFS (które są zachowywane podczas przenoszenia pliku, więc może spowodować przedwczesne usunięcie zmodyfikowanego pliku)
  • Powinien mieć minimalny, jeśli jakikolwiek wpływ na wydajność. Nie ma potrzeby przechowywania bazy danych lub listy nazw plików i / lub skrótów.
  • Nic nie psuje się okropnie, jeśli skrypty nie działają. Do aktualizacji daty nie jest wymagana żadna usługa ani stale działający program. Tylko kilka zaplanowanych zadań. Rozwiązania, które polegają na sprawdzaniu nowych plików i aktualizowaniu ich ostatniej modyfikacji do chwili obecnej, mogą zakończyć się usunięciem nowych plików, jeśli usługa ulegnie awarii lub przejdzie w stan wyścigu.

Jedyny problem, jaki widzę, to kopiowanie pliku, który został zmodyfikowany 20 lat temu do folderu upuszczania. Wydaje mi się, że w większości przypadków nie jest to duży problem, ale może się pojawić.


0

Możesz sformalizować dodawanie plików do pola rozwijanego za pośrednictwem strony internetowej, która ma „upload” IFRAME. Użytkownik może następnie „opublikować” plik, który wywołuje zadanie PHP / ASP na serwerze, które pobiera plik i umieszcza go w lokalizacji pucker. PHP / ASP może wykonywać dowolną liczbę operacji indeksu / analizy.


0

Jeśli ktoś skopiuje lub przeniesie pliki tutaj, chciałbym, aby zegar zaczął odtąd odtąd. Jednak data ostatniej modyfikacji i data utworzenia pliku nie zostaną zaktualizowane, chyba że ktoś faktycznie zmodyfikuje plik.

Stworzyłbym skrypt, który będzie działał jako zaplanowane zadania co pięć minut i robi dwie rzeczy.

  1. Pierwsza akcja spowoduje skopiowanie dowolnego pliku skopiowanego do folderu, umieszczenie przedrostka w pliku i usunięcie oryginału. Zapewni to, że data utworzenia pliku będzie jednolita dla aplikacji.
  2. Druga akcja obejrzy wszystkie pliki z określonym z góry prefiksem (ustawionym za pomocą akcji 1) i usunie wszystkie z datą utworzenia starszą niż X dni. To rozwiązałoby problem modyfikacji / daty dostępu.

0

Istnieje istniejący mechanizm oznaczania plików, bit Archiwum. Jest tam od początku DOS i jest obecny zarówno w FAT, jak i NTFS.

Zasadniczo każdy plik ma domyślnie ustawiony bit archiwum. Jeśli zobaczysz plik z bitem archiwum w swoim folderze upuszczania, (1) wyczyść ten bit i (2) ustaw datę na dzisiaj. Jeśli widzisz plik bez tego bitu z datą <= 7 dni w przeszłości, usuń go.

Jeśli użytkownik zapisuje plik, gdy znajduje się on w folderze upuszczania, jego bit archiwum jest ustawiany ponownie, więc jego żywotność jest również resetowana do 7 dni. W końcu to nowy plik.

Możesz teraz bezpiecznie używać FileSystemWatcher. Wszelkie problemy (takie jak zduplikowane zdarzenia, przepełnienie bufora, utrata szczegółowych informacji) nie mają już znaczenia, ponieważ wszystkie istotne informacje znajdują się w metadanych pliku.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.