K3b

[corman]

Nagrałem płyty pod K3b i też przez niego usunąłem już nagrane pliki. I teraz problem polega na tym że plików tych nie ma w katalogu ani w śmietniku, ale i miejsce na dysku się nie zwiększyło. Jak ktoś wie jak sobie z tym poradzić to proszę o pomoc. P.S. a i jeszcze jedno, że po usunięciu innych plików normalnie z katalogu a następnie z kosza zwiększa się miejsce na dysku.

[@Sorror]

Napisz jeszcze raz w czym dokładnie jest problem, ja przynajmniej niewiele rozumiem.

[@WalDo]

[...]ja przynajmniej niewiele rozumiem.

Za sorrorem

 

[corman]

No więc tak: po nagraniu plików i usunięciu ich z dysku w k3b, poprzez okno wyboru plików do nagrania, znikają one z katalogu w którym były, lecz przy sprawdzaniu wolnego miejsca, wynika że dane pliki nadal są na dysku (choć niewidoczne), ponieważ ilość wolnego miejsca jest taka sama a powinna zwiększyć się o jakieś 20 GB.

 

[@Sorror]

Zapewne k3b przenosi (a tak naprawdę przeadresowuje) takie pliki do własnego "kosza". Możesz spróbować znaleźć odpowiednią lokalizację przez przejrzenie konfiguracji lub dokumentacji (nie korzystam z k3b), lub też odpalić updatedb i znaleźć plik(-i) poprzez locate <nazwa>.

[@WalDo]

Zapewne k3b przenosi (a tak naprawdę przeadresowuje) takie pliki do własnego "kosza".

Mnie się wydaje, że okno k3b, w którym wybieramy pliki do nagrania działa jak zwyczajny menedżer plików. Pliki są usuwane całkowicie lub przenoszone do kosza (tego "ogólnosystemowego").

 

[@Sorror]

Mnie się wydaje, że okno k3b, w którym wybieramy pliki do nagrania działa jak zwyczajny menedżer plików. Pliki są usuwane całkowicie lub przenoszone do kosza (tego "ogólnosystemowego").

 

Tak pomyślałem na początku, ale po analizie 1 posta kolegi widać, że nie są:

 

I teraz problem polega na tym że plików tych nie ma w katalogu ani w śmietniku, ale i miejsce na dysku się nie zwiększyło

[@WalDo]

Tak pomyślałem na początku, ale po analizie 1 posta kolegi widać, że nie są:

Racja.

Nigdy nie usuwałem plików przez k3b, ale chyba będę musiał spróbować i przy okazji namierzyć gdzie się chowają "śmieci".

 

[@Sorror]

Nie czekając na odpowiedź cormana, jeśli rzecz nie w powyższym, to może k3b odpalane jest spod innego usera niż środowisko? Wtedy pliki znajdowałyby się w koszu użytkownika odpalającego aplikację.

[Adi1981]

A ja bym spróbował po prostu resetnąć system.

Wiem że to rozwiązanie rodem z windowsa, ale fedora (a może ext3) czasem ma to do siebie, że nie zwalnia wolnego miejsca po usunięciu plików. Sam tak miałem kilka razy, i szczerze nie mam pojęcia czym to może być spowodowane. Można też spróbować wcześniej fsck, ale u mnie zazwyczaj dopiero restart pomagał w takiej sytuacji.

[@Sorror]

fedora (a może ext3) czasem ma to do siebie, że nie zwalnia wolnego miejsca po usunięciu plików. Sam tak miałem kilka razy, i szczerze nie mam pojęcia czym to może być spowodowane.

 

O tym pierwszy raz słyszę i w takie właściwości pakietów base Fedory nie uwierzę, natomiast może to być kwestia braku odpowiedniej komunikacji e.g. managerem plików. Kiedy następny raz pojawi się taka sytuacja sprawdź rozmiar dysku z konsoli (du -h katalog, z tego co pamiętam du samo z siebie rozmiar katalogów sprawdza rekursywnie).

[corman]

Sprawdzałem katalogi menadżerem plików (mc), nawet te ukryte ( trash, tmp, kde bo jak wiadomo k3b korzysta z niego) i nigdzie nie ma śladów po usuniętych plikach. sprawdzałem tak jak Sorror pisał poprzez "du -h" i wychodzi że katalog "home" ma 116 GB, a sprawdzając poprzez "właściwości" katalogu z poziomu X, wychodzi raptem 94 GB. P.S. restart nic nie daje.

[@WalDo]

[...]a sprawdzając poprzez "właściwości" katalogu z poziomu X, wychodzi raptem 94 GB

Twoje sprawdzenia nie muszą być miarodajne. Być może "właściwości katalogu" nie liczą np. plików ukrytych. Dodatkowo dochodzi sposób liczenia bajtów a właściwie kB, MB, GB itd. Tzn. jedno narzędzie może liczyć "po Bożemu" czyli 1kB = 1024 B a inne może zwyczajnie odcinać trzy ostatnie znaczące cyfry i wtedy jeśli mamy dwa pliki po 1800 bajtów każdy, to jedno narzędzie pokaże ~3,52 a drugie raptem 2, góra 3 kB (np. część całkowita z 1800/1000+1800/1000).

 

Wg mnie miarodajny test to sprawdzenie ile zajmuje dany katalog z pomocą du (zostawiłbym w spokoju opcję "-h" - human readable, bo nie wiadomo jak to zaokrągla), potem usunięcie jakiegoś dużego pliku, czy dużej liczby plików z katalogu i ponowne sprawdzenie zajmowanego miejsca tym samym narzędziem (du)

 

[EDIT]Przepraszam, moj błąd - oczywiście, że wiemy jak zaokrągla du. Dzieli "poprawnie" czyli przez 1024.

[Adi1981]

O tym pierwszy raz słyszę i w takie właściwości pakietów base Fedory nie uwierzę, natomiast może to być kwestia braku odpowiedniej komunikacji e.g. managerem plików. Kiedy następny raz pojawi się taka sytuacja sprawdź rozmiar dysku z konsoli (du -h katalog, z tego co pamiętam du samo z siebie rozmiar katalogów sprawdza rekursywnie).

 

Być może masz rację i wina leży po stronie aplikacji a nie systemu. Nie pamiętam dokładnie w jakich sytuacjach to było, ale na ogół wolę usuwać rzeczy z konsoli (ewentualnie mc), wiec ciężko mi teraz powiedzieć czy to faktycznie wina komunikacji i/lub alpikacji. Na 100% jedynie wiem że takie sytuacje się zdarzały usuwając pliki z poziomu amule'a. Natomiast du i df samo w sobie nic nie dawało, jako że pokazywało miejsce tak jak bym plików nie usuwał (z tego co pamiętam oczywiście, ale na 85% jestem pewien że tak było). Jak jeszcze uda mi się takie coś wyłapać to spróbuję dokładniej przetestować.

[@Sorror]

sprawdzałem tak jak Sorror pisał poprzez "du -h" i wychodzi że katalog "home" ma 116 GB, a sprawdzając poprzez "właściwości" katalogu z poziomu X, wychodzi raptem 94 GB

 

Czyli tak jak przypuszczałem, kwestia managera. Wiemy więc już, że pliki faktycznie zostały usunięte i nie ma ich na dysku. Zależnie od managera plików, z jakiego korzystasz możesz mu wyczyścić kecza, aby wymusić następnym razem ponowne fizyczne sprawdzenie objętości folderu.