Kiedy próbowałem zarządzać koszem z zamontowanych woluminów NTFS, skończyłem czytając na nim referencje FreeDesktop.org .
Grzebiąc i robiąc testy, zdałem sobie sprawę, że Ubuntu / Gnome nie przestrzega specyfikacji w 100%. Dlatego:
W przypadku partycji innych niż / partycja zawsze używa
<driveroot>/.Trash-<uid>, nigdy nie była używana<driveroot>/.Trash/<uid>, nawet jeśli wcześniej ją utworzyłem. Chociaż to działa, to denerwujące: jeśli mam 15 użytkowników, mam 15/.Trash-xxxfolderów na dysku, podczas gdy inne podejście dałoby jeden folder (z 15 podfolderami). To „zanieczyszczenie” w moich dyskach jest bardzo nieprzyjemne. A specyfikacje mówią „ Jeśli$topdir/.Trashkatalog jest nieobecny,$topdir/.Trash-$uidnależy go użyć ”. Cóż, jest obecny, więc dlaczego go nigdy nie używa?Kosz root nie działa, przynajmniej nie po wyjęciu z pudełka. Otwórz nautilus jako root i kliknij kosz; daje błąd. Spróbuj usunąć dowolny plik, mówi „nie można przenieść go do kosza”. Ok, wiem, że można to naprawić, tworząc
/root/.local/share. Ale spec mówi, że „ Domowy katalog śmieci POWINIEN zostać utworzony automatycznie dla każdego nowego użytkownika. Jeśli ten katalog jest potrzebny do operacji kosza, ale nie istnieje, implementacja POWINIEN go automatycznie utworzyć, bez żadnych ostrzeżeń ani opóźnień. ”. Skąd więc błąd? Pluskwa?Dlaczego muszę zmieniać
/etc/fstabwpisy dla zamontowanych woluminów, dodając opcje takie jak UID i GUID, jeśli woluminy są już zamontowane jako RW dla wszystkich?
To tylko niektóre przykłady odchyleń od normy. Pytanie brzmi:
„Jeśli Ubuntu nie przestrzega w 100% specyfikacji, JAK dokładnie działa kosz? GDZIE mogę znaleźć informacje techniczne na temat implementacji kosza przez Ubuntu?”
Nawiasem mówiąc: jeśli zdarza się, że Ubuntu postępuje zgodnie ze specyfikacjami, proszę powiedz mi, co robię źle, szczególnie w odniesieniu do problemu /.Trash-<uid>vs./.Trash/<uid>
Dzięki!
EDYTOWAĆ:
Więcej informacji:
Jeśli dany fs nie obsługuje bitu lepkiego (VFAT, NTFS), prawdopodobnie również nie ma uprawnień (przynajmniej VFAT na pewno nie). Co zatem uniemożliwia jednemu użytkownikowi wyczyszczenie
/przywracania innych użytkowników./Trash-xxx? Jeśli ktoś może czytać / pisać własne Kosze, może zrobić to samo dla całego dysku, w tym dla innych śmieci, prawda? Czy też Gnome ma jakąś „dodatkową” ochronę./Trash-xxxfolderów na VFAT / NTFS fs?Jeśli Linux może „emulować” uprawnienia do plików podczas montowania NTFS, edytując
/fstabopcje uid i gid, to czy może również „emulować” lepki bit? Naprawdę wolałbym użyć/.Trash/xxxformatu ...W przypadku problemu z rootem: w przypadku partycji / mogę użyć kosza jako root, i to idzie do
/root/.local/share/Trash. Ale jeśli kliknę „Nautilus” „Kosz” (jako root), pojawi się błąd. Nie ty Pliki są więc poprawnie przesyłane, ale nie mam do nich dostępu. Wszystko, co mogę zrobić, to ręcznie „wyczyścić” je (usuwając pliki/root/.local/share/Trash), ale przywrócenie byłoby bardzo trudne (otwieranie plików informacyjnych i ręczne przenoszenie itp.).W przypadku partycji innych niż / (a przynajmniej VFAT / NTFS) nie mogę nawet użyć kosza jako root: nie tworzy
./Trash-0folderu, po prostu mówi „Nie możesz kosza, chcesz trwale usunąć?” Dlaczego?O fstab: używam go do stałego montowania dla moich partycji NTFS. Mam kilka, a jeśli nie są „wstępnie zamontowane”, naprawdę zaśmiecają pulpit i / lub Nautilusa. Wolałbym mieć go wstępnie zamontowane, zintegrowane w moim systemie plików, w elementach mocujących takich jak
/data,/windows/xp,/windows/vista, i tak dalej, i urlopu/mediai jego „podłączanie / odłączanie” elastyczność tylko dla napędów naprawdę wymiennych.
Więc jeśli Ubuntu / Gnome naprawdę postępuje zgodnie ze specyfikacją, czy jest jakiś sposób, aby naprawić problemy z rootem i „emulować” lepki bit dla (przynajmniej) moich stałych partycji NTFS?