Làm thế nào để xóa thư mục không thể xóa này?


40

Tôi đã gỡ bỏ một tệp tar bị hỏng và quản lý để kết thúc với một số thư mục mà tôi không thể xóa, Nếu tôi cố xóa nó, có vẻ như nó không thể được tìm thấy, nhưng lshiển thị nó, cả bash và python tôi nhận được hành vi tương tự, ngoại trừ ngay sau khi tôi cố gắng xóa nó rm -rf, lsphàn nàn rằng nó không thể tìm thấy nó, sau đó nó liệt kê nó (xem bên dưới sau rm -rf). Các findlệnh show file có mặt, nhưng tôi vẫn không thể nghĩ ra một cách để xóa nó.
Đây là những nỗ lực của tôi:

Ở đây bạn thấy cả hai lsfindđồng ý chúng tôi có một thư mục,

rl]$ ls
mikeaâ??cnt
rl]$ find -maxdepth 1 -type d -empty -print0  
./mikeaâcnt 

Nhưng tôi không thể xóa nó:

rl]$ find -maxdepth 1 -type d -empty -print0 |  xargs -0 rm -f -v 
rm: cannot remove `./mikeaâ\302\201\302\204cnt': Is a directory
rl]$ ls
mikeaâ??cnt

Tôi có thể cdlàm điều đó và nó trống rỗng:

rl]$ cd mikeaâ^Á^Äcnt/
mikeaâ^Á^Äcnt]$ ls
mikeaâ^Á^Äcnt]$ pwd
.../rl/mikeaâcnt


mikeaâ^Á^Äcnt]$ cd ../
rl]$ ls
mikeaâ??cnt

xem bên dưới không phải là một tệp đơn giản mà là một thư mục, cộng với lshành vi buồn cười sau khi rm -rf nó nói rằng nó không thể tìm thấy tệp sau đó liệt kê nó ngay sau:

rl]$ rm mikeaâ^Á^Äcnt/
rm: cannot remove `mikeaâ\302\201\302\204cnt/': Is a directory
rl]$ rm -rf  mikeaâ^Á^Äcnt/
rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt
rl]$ 

Vì vậy, đây là nỗ lực với python, tệp được tìm thấy, nhưng tên không thể sử dụng được như một tên có thể bị xóa:

rl]$ python 
Python 2.6.6 (r266:84292, Jul 10 2013, 22:48:45) 
[GCC 4.4.7 20120313 (Red Hat 4.4.7-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> import shutil
>>> os.listdir('.')
['mikea\xc3\xa2\xc2\x81\xc2\x84cnt']
>>> shutil.rmtree(os.listdir('.')[0] )
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python2.6/shutil.py", line 204, in rmtree
    onerror(os.listdir, path, sys.exc_info())
  File "/usr/lib64/python2.6/shutil.py", line 202, in rmtree
    names = os.listdir(path)
OSError: [Errno 2] No such file or directory: 'mikea\xc3\xa2\xc2\x81\xc2\x84cnt'

ngay cả khi tôi sử dụng tab hoàn thành, tên nó vẫn không thể sử dụng được:

rl]$ rm -rf mikeaâ^Á^Äcnt 
rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt

sử dụng tên mà python hiển thị với bash tôi nhận được điều này:

rl]$ rm -rf "mikea\xc3\xa2\xc2\x81\xc2\x84cnt"
rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt

Có bất cứ điều gì tôi có thể làm để thoát khỏi thư mục tham nhũng này? Hệ thống tập tin cơ bản (NFS) có vẻ hoạt động và không có vấn đề nào khác được báo cáo, và tôi đã không gặp vấn đề nào như vậy cho đến khi tập tin tar bị hỏng.

EDIT: Ở đây đang sử dụng tùy chọn findriêng -execđể gọirm

rl]$ find -maxdepth 1 -type d -empty -exec rm -f {} \;
find: `./mikeaâ\302\201\302\204cnt': No such file or directory
rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt
rl]$

nhưng tập tin vẫn ở đó, ( lsphàn nàn rằng nó không thể tìm thấy nó, nhưng sau đó vẫn hiển thị nó)

EDIT thứ 2:

rl]$ find -maxdepth 1 -type d -empty -exec rm -rf {} \;
find: `./mikeaâ\302\201\302\204cnt': No such file or directory
rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt

Hành vi vẫn không thay đổi, tập tin vẫn hiện diện

EDIT thứ 3:

rl]$ ls
mikeaâ??cnt
rl]$ find -maxdepth 1 -type d -empty -exec rm -rf {} + 
rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt

Dường như có nhiều cái tên hơn là mikeaâcntnhìn vào đầu ra của nỗ lực trăn mikea\xc3\xa2\xc2\x81\xc2\x84cntvà ảnh chụp màn hình này:

đầu ra ls

EDIT thứ 4: Đây là nỗ lực với một thẻ hoang dã:

rl]$ echo * 
mikeaâcnt
rl]$ echo mike* 
mikeaâcnt
rl]$ rm -rf mike*
rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt

và địa phương của tôi:

rl]$  locale
LANG=en_US.utf8
LC_CTYPE="en_US.utf8"
LC_NUMERIC="en_US.utf8"
LC_TIME="en_US.utf8"
LC_COLLATE="en_US.utf8"
LC_MONETARY="en_US.utf8"
LC_MESSAGES="en_US.utf8"
LC_PAPER="en_US.utf8"
LC_NAME="en_US.utf8"
LC_ADDRESS="en_US.utf8"
LC_TELEPHONE="en_US.utf8"
LC_MEASUREMENT="en_US.utf8"
LC_IDENTIFICATION="en_US.utf8"
LC_ALL=

Chỉnh sửa lần thứ 5:

rl]$ ls -i 
ls: cannot access mikeaâcnt: No such file or directory
? mikeaâ??cnt

nhưng cũng thay đổi hành vi, bây giờ lscd làm điều này:

rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt
rl]$ cd mikeaâ^Á^Äcnt 
mikeaâcnt: No such file or directory.

Điều này đã xảy ra sau những nỗ lực xóa, tôi nghĩ rằng đó có thể là vấn đề NFS như được đề xuất trong một trong những câu trả lời ở đây bởi vinc17.

EDIT thứ 6: Đây là đầu ra của lsofls -a

rl] $ / usr / sbin / lsof mikeaâ ^ Á ^ cnt lsof: lỗi trạng thái trên mikeaâ \ xc2 \ x81 \ xc2 \ x84cnt: Không có tệp hoặc thư mục như vậy

ở trên là sai, đây là cách lsofgọi đúng : (rl là thư mục cha)

rl]$ /usr/sbin/lsof | grep mike | grep rl 
tcsh      11926   mike  cwd       DIR   0,33     4096 19569249 /home/mike/mish/rl
lsof      14733   mike  cwd       DIR   0,33     4096 19569249 /home/mike/mish/rl
grep      14734   mike  cwd       DIR   0,33     4096 19569249 /home/mike/mish/rl
grep      14735   mike  cwd       DIR   0,33     4096 19569249 /home/mike/mish/rl
lsof      14736   mike  cwd       DIR   0,33     4096 19569249 /home/mike/mish/rl
rl]$ 

rl]$ ls -a
ls: cannot access mikeaâcnt: No such file or directory
.  ..  mikeaâ??cnt

Chỉnh sửa lần thứ 7: di chuyển sẽ không hoạt động, (tôi đã thử trước tất cả điều này, nhưng tôi không lưu kết quả đầu ra), nhưng nó có cùng một vấn đề với lsrm với tệp.

EDIT thứ 8: đây là sử dụng các ký tự hex như được đề xuất:

 rl]$ ls --show-control-chars | xxd
0000000: 6d69 6b65 61c3 a2c2 81c2 8463 6e74 0a    mikea......cnt.
rl]$ rmdir $'mikea\6d69\6b65\61c3\a2c2\81c2\8463\6e74\0acnt' 
rmdir: failed to remove `mikea\006d69\006b651c3\a2c2\\81c2\\8463\006e74': No such file or directory
rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt
rl]$

Chỉnh sửa thứ 9: cho statlệnh:

 rl]$ stat  mikeaâ^Á^Äcnt 
stat: cannot stat `mikeaâ\302\201\302\204cnt': No such file or directory
 rl]$

Dường như thậm chí nhiều khả năng từ tất cả các đầu ra, có một lỗi hoặc hành vi sai trái NFS khác như được đề xuất trong các ý kiến.

Chỉnh sửa 10: Đây là đầu ra strace trong một ý chính vì nó quá lớn, đầu ra của nó hoặc hai lệnh này:

strace -xx rmdir ./* | grep -e '-1 E'`
strace -xx -e trace=file ls -li`

https://gist.github.com/mikeatm/e07fa600747a4285e460

Chỉnh sửa 11: Vì vậy, trước khi ở trên rmdirtôi nhận thấy rằng tôi có thể cdvào thư mục, nhưng sau khi rmdirtôi không thể cdmột lần nữa, tương tự như ngày hôm qua. Các tập tin ...đã có mặt:

rl]$ ls
mikeaâ??cnt
rl]$ cd mikeaâ^Á^Äcnt/
mikeaâ^Á^Äcnt]$ ls
mikeaâ^Á^Äcnt]$ ls  -a
.  ..
mikeaâ^Á^Äcnt]$ cd ../

Chỉnh sửa cuối cùng: Tôi thấy một quản trị viên địa phương về vấn đề này và nó đã được xử lý bằng cách đăng nhập vào chính máy chủ và xóa từ đó. Lời giải thích từ họ là nó có thể là một vấn đề với các bộ ký tự trong tên không phù hợp.


Có một lý do nào đó khiến findđầu ra của bạn chuyển sang một lệnh khác thay vì chỉ sử dụng exectùy chọn đó?
HalosGhost

@HalosGhost không có lý do, xem chỉnh sửa để biết thêm thông tin về câu hỏi của bạn
mike-m

2
Là một người có rất ít kinh nghiệm với unix và linux, đây là ý tưởng của tôi: hãy thử đổi tên thư mục thành thứ gì đó mà không sử dụng các ký hiệu đó mv. có lẽ bạn có thể xóa nó sau đó Ngoài ra, bạn có thể thử di chuyển thư mục đến cấp thư mục sâu hơn (có thể bằng ký tự đại diện) và sau đó xóa thư mục bạn đã chuyển đến.
Nzall

4
Tôi nghi ngờ thư mục chỉ tồn tại trong bộ nhớ trên máy khách và đã mất trên máy chủ. Bạn đã thử umount nó và gắn nó một lần nữa? Bạn đã thử khởi động lại máy khách chưa? Nó có thể nhìn thấy trên các khách hàng khác?
kasperd

6
@ mike-m Có vẻ như bạn đã gặp phải lỗi NFS, có thể là trong máy chủ NFS. Hoặc là hoặc hệ thống tập tin tham nhũng trên máy chủ. Tôi nghi ngờ bạn thực sự có thể làm bất cứ điều gì khác ngoài việc chờ (các) quản trị viên máy chủ NFS xử lý.
derobert

Câu trả lời:


11

Đoạn trích sau đây từ bài tiểu luận này có khả năng giải thích lý do tại sao thư mục đó từ chối bị xóa:

NFSv4 yêu cầu tất cả các tên tệp được trao đổi bằng UTF-8 qua dây dẫn. Thông số kỹ thuật của NFSv4, RFC 3530, nói rằng tên tệp phải được mã hóa UTF-8 trong phần 1.4.3: Cảnh Trong một sự khởi hành nhẹ, tên tệp và thư mục được mã hóa bằng UTF-8 để xử lý các vấn đề cơ bản về quốc tế hóa. cũng được tìm thấy trong phần NFS 4.1 RFC (RFC 5661) mới hơn 1.7.3. Máy khách Linux NFS hiện tại chỉ đơn giản chuyển thẳng tên tệp mà không cần chuyển đổi từ ngôn ngữ hiện tại sang và từ UTF-8. Sử dụng tên tệp không phải UTF-8 có thể là một vấn đề thực sự trên hệ thống sử dụng hệ thống NFSv4 từ xa; bất kỳ máy chủ NFS nào tuân theo đặc tả NFS được cho là từ chối tên tệp không phải UTF-8. Vì vậy, nếu bạn muốn đảm bảo rằng các tệp của bạn thực sự có thể được lưu trữ từ máy khách Linux đến máy chủ NFS, thì hiện tại bạn phải sử dụng tên tệp UTF-8. Nói cách khác,

UTF-8 là một cách tiếp cận dài hạn. Các hệ thống phải hỗ trợ UTF-8 cũng như nhiều bảng mã cũ hơn, giúp mọi người có thời gian chuyển sang UTF-8. Để sử dụng UTF-8 ở mọi nơi, tất cả các công cụ cần được cập nhật để hỗ trợ UTF-8. Nhiều năm trước, đây là một vấn đề lớn, nhưng vào năm 2011, đây thực chất là một vấn đề đã được giải quyết và tôi nghĩ rằng quỹ đạo rất rõ ràng đối với một vài hệ thống kéo dài đó.

Không phải tất cả các chuỗi byte là UTF-8 hợp pháp và bạn không muốn tìm ra cách hiển thị chúng. Nếu hạt nhân thi hành các hạn chế này, đảm bảo rằng chỉ các tên tệp UTF-8 được cho phép, thì không có vấn đề gì ... tất cả các tên tệp sẽ là UTF-8 hợp pháp. Hàm utf8_check C của Markus Kuhn có thể nhanh chóng xác định xem một chuỗi có hợp lệ UTF-8 hay không.

Hệ thống tập tin nên yêu cầu tên tệp đáp ứng một số tiêu chuẩn, không phải vì một số nhu cầu xấu để kiểm soát mọi người, mà đơn giản là để tên luôn có thể được hiển thị chính xác sau đó. Việc thiếu các tiêu chuẩn làm cho mọi thứ khó khăn hơn cho người dùng, không dễ dàng hơn. Tuy nhiên, hệ thống tập tin không buộc tên tệp phải là UTF-8, vì vậy nó có thể dễ dàng có rác.


Điều này dường như lặp lại lời giải thích từ các quản trị viên địa phương, tôi sẽ đánh dấu đây là câu trả lời theo lời giải thích của quản trị viên. Xem bản chỉnh sửa cuối cùng của tôi
mike-m

19

Một cách để xóa các tập tin / direcories như thế này là bằng cách tham chiếu inode của chúng.

Để tìm các nút cho các phần tử trong thư mục hiện tại:

ls -i
14813568 mikeaâcnt

Để xóa cái này:

find . -inum 14813568 -delete

vui lòng xem chỉnh sửa thứ 5.
mike-m

4
Không, điều này không xóa các tập tin bằng inode của họ. Cái này tìm tên tệp cho inode đã cho, rồi xóa tệp theo tên của nó. Không thể giúp được ở đây, vì một nỗ lực đã được thực hiện với tên chính xác (cùng với các lần thử khác có tên không chính xác).
Gilles 'SO- ngừng trở nên xấu xa'

@Gilles - về mặt kỹ thuật, nó tìm kiếm một nha khoa inode và trả lại tên tệp, nhưng tôi đồng ý.
mikeerv

1
@Nicolai không giúp tôi. Thư mục không trống rỗng xuất hiện.
nhiễu xạ

1
Vâng, hah, câu chuyện hài hước về điều này: Tập tin tôi đang cố gắng xóa có ?tham chiếu inode của nó. Làm thế nào để bạn xóa nó sau đó?
Nic Hartley

7

Bạn không nên sử dụng các ký tự không phải ASCII trong dòng lệnh vì như bạn có thể thấy, vì một số lý do, chúng không nhất thiết phải tương ứng với tên tệp (Unicode có nhiều cách khác nhau để thể hiện các chữ cái có dấu). Cái gì đó như:

rm -rf mike*

nên hoạt động vì tên tệp được tạo trực tiếp bởi shell. Nhưng hãy chắc chắn rằng chỉ có một trận đấu (thực hiện echo mike*đầu tiên để xác nhận).

Chà, nếu cdhoạt động, thì không có lý do tại sao rmhoặc lsnên nói No such file or directory, để vấn đề có thể ở cấp hệ thống tệp.

Lưu ý: Không sử dụng lsđể tìm xem thư mục có trống không, nhưng ls -a.

Thư mục vẫn có thể được sử dụng bởi một quy trình khác (bao gồm cả nếu đó là cwd của một quy trình nào đó). IMHO, đó là lý do tại sao nó vẫn "tồn tại" nhưng có thể gây ra lỗi, ví dụ như với ls; lsofcó thể cung cấp cho bạn một số thông tin, nhưng với NFS, bạn cần tìm máy nào sử dụng nó. Đặc biệt với NFS, điều này có thể mang lại những lỗi lạ. ls -atrong thư mục mẹ có thể hiển thị cho bạn .nfs*tệp / thư mục trong một số trường hợp.

Khi bạn nhận được:

$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt

Tôi nghi ngờ rằng tệp vẫn tồn tại trong bảng thư mục do bộ đệm NFS và / hoặc vì nó được sử dụng bởi một quy trình khác, nhưng không có thông tin liên quan. Khi lscố gắng lấy thông tin về chính tệp đó, nó sẽ gặp lỗi vì bản thân tệp không còn tồn tại (nó chỉ nằm trong bảng thư mục), do đó lỗi hiển thị. Sau đó lsxuất tên tệp vì nó nằm trong bảng thư mục. Việc bạn có dấu chấm hỏi trong một trường hợp nhưng không phải trong trường hợp khác là do lỗi hiển thị của lsIMHO (không liên quan đến vấn đề của bạn).


tôi đã thử một ký tự đại diện trước đó, nó không hoạt động và tôi đã không đăng được nỗ lực đó trong câu hỏi của mình, tôi sẽ cập nhật với kết quả
mike-m

Xem chỉnh sửa thứ ba của tôi. IMHO điều này là do NFS (có thể không tham nhũng, nhưng bộ nhớ đệm xấu) và có thể thực tế là một quá trình khác đang sử dụng thư mục. Trong một số trường hợp, người ta cần khởi động lại mọi thứ (máy chủ và máy khách).
vinc17

Có lẽ điều này có thể giải thích mọi thứ, nhưng tôi không thể chắc chắn vì tôi không có các đặc quyền để đưa nó xuống để kiểm tra. Xem bản chỉnh sửa thứ 5.
mike-m

1
@ vinc17 Vui lòng không sử dụng "EDIT" trong câu trả lời của bạn, vì đối với người đọc mới không có ý nghĩa (đã có lịch sử chỉnh sửa)
Bernhard

iv đã thêm một số đầu ra lsof, không chắc nó có thể cho bạn biết bất cứ điều gì không,
mike-m

3

Tôi đã đích thân thử nghiệm sử dụng findcủa -execchỉ thị:

$ mkdir -p mikeaâcnt
$ ls
mikeaâcnt
$ find -maxdepth 1 -type d -empty -exec rm -rf {} +
$ ls
$ 

Các thư mục đã được tạo chính xác và loại bỏ chính xác.

Như @Igeorget đã chỉ ra , có một phương thức thậm chí còn đơn giản hơn nếu bạn có GNU find:

$ find -maxdepth 1 -type d -empty -delete

Tôi cũng đã thử lệnh này và nó hoạt động chính xác


Và nếu bạn sử dụng công cụ tìm kiếm của GNU, thì cũng có một -deletetùy chọn.
lgeorget

Vui lòng xem bản chỉnh sửa thứ 3,
mike-m

1

Tôi đã có cùng một vấn đề, tôi tin. Tôi đã thấy vấn đề trước đó với một tên tệp của . lstrong trường hợp này hiển thị các tập tin như â??, nhưng tôi đã có thể xóa nó với rm ☃.

Điều này dẫn tôi đến cách sau đây để chuyển đổi tên sai thành đúng:

Đầu tiên lấy byte của tên tệp:

$ ls --show-control-chars | xxd
0000000: 6d69 6b65 61c3 a2c2 81c2 8463 6e74 0a    mikea......cnt.

Sau đó giải mã các byte này dưới dạng UTF-8, để lấy mã điểm unicode, sử dụng đầu vào thập lục phân của trang web này, ví dụ: http://software.hixie.ch/utilities/cgi/unicode-decoder/utf8-decoder

U+006D LATIN SMALL LETTER M character
U+0069 LATIN SMALL LETTER I character
U+006B LATIN SMALL LETTER K character
U+0065 LATIN SMALL LETTER E character
U+0061 LATIN SMALL LETTER A character
U+00E2 LATIN SMALL LETTER A WITH CIRCUMFLEX character (&#x00E2;)
U+0081 <control> character (&#x0081;)
U+0084 <control> character (&#x0084;)
U+0063 LATIN SMALL LETTER C character
U+006E LATIN SMALL LETTER N character
U+0074 LATIN SMALL LETTER T character

Lưu ý rằng tất cả đều ở dưới ranh giới byte. Chúng tôi có được các byte sau:

6D 69 6B 65 61 E2 81 84 63 6E 74

Nếu chúng tôi xử lý chuỗi này tại UTF-8, chúng tôi sẽ nhận được:

U+006D LATIN SMALL LETTER M character
U+0069 LATIN SMALL LETTER I character
U+006B LATIN SMALL LETTER K character
U+0065 LATIN SMALL LETTER E character
U+0061 LATIN SMALL LETTER A character
U+2044 FRACTION SLASH character (&#x2044;)
U+0063 LATIN SMALL LETTER C character
U+006E LATIN SMALL LETTER N character
U+0074 LATIN SMALL LETTER T character

Và do đó, tên tệp của bạn là : mikea⁄cnt, với dấu gạch chéo thay vì chuyển tiếp thông thường. Bây giờ bạn có thể chuyển tên này cho rmdir.


Đó là khéo léo, nếu tôi gặp lại điều này, il hãy ghi nhớ điều này. tốt một. +1
mike-m

0

Sau khi nhận được mã hex chính xác của tên tệp / thư mục (sử dụng bất kỳ phương thức nào tôi thấy phù hợp, tôi có thể chọn ls --show-control-chars | xxd), một số cấu trúc đặc biệt nên được sử dụng để giải quyết các ký tự đó khi chạy trong bash:

rmdir $'mikea\xc3\xa2\xc2\x81\xc2\x84cnt'

Mặt khác, dấu gạch chéo ngược được coi là dấu gạch chéo ngược vani.


Xin hãy xem bản chỉnh sửa của tôi (bản chỉnh sửa thứ 8)
mike-m

@ mike-m Tất nhiên điều đó không tồn tại, bởi vì lsbao gồm dòng mới trong dữ liệu đầu ra và "cnt" được sao chép. Có lẽ bạn có thể thử trực tiếp sao chép và dán dòng trong câu trả lời của tôi và xem nó có hiệu quả không?
Abel Cheung

Không, đây vẫn là: `` `
mike-m

Trong trường hợp đó, rất có thể là sự kết hợp của vấn đề NFS và ngôn ngữ ngăn chặn hầu hết các tiện ích hệ thống truyền các byte không phải UTF8 không chính xác. Và có vẻ như việc loại bỏ inode đã làm tình hình tồi tệ hơn. Còn bây giờ, cách duy nhất tôi có thể nghĩ đến là thiết lập hệ thống của bạn vào một môi trường locale-miễn phí (sử dụng "C" locale cho LC_*LANGbiến env), và gắn kết NFS mà không cần bất kỳ tùy chọn bộ ký tự
Abel Cheung

0

Bạn đã cố gắng sử dụng rm -rf ./mikeaâcnthoặc rm -rf "./mikeaâcnt"hoặc một đường dẫn tuyệt đối? Ngoài ra thay vì rm, hãy thử rmdir ./mikeaâcnt.


một phần của vấn đề là các ký tự mikeaâcntdường như không phải là tên tệp, nhưng ls hiển thị, xem bản chỉnh sửa thứ 3
mike-m

0

Bạn đã thử lấy inode của tập tin đó bằng stat:

stat mike*

Điều đó sẽ cung cấp cho bạn số inode (và dữ liệu khác), và sau đó bạn có thể cố gắng xóa nó.


iv đã thêm một bản chỉnh sửa với statBehour,
mike-m

0

Tôi đã có vấn đề tương tự. Bạn có Gnome, KDE hoặc một số loại Xwindow DM không?. Nếu bạn mở trình duyệt tệp của bạn và xóa tệp từ đó.

Nó nên hoạt động.

Tôi muốn xem một giải pháp từ dòng lệnh, nhưng trong trường hợp của tôi và sau khi mất rất nhiều thời gian cố gắng tìm ra cách loại bỏ nó khỏi dòng lệnh tôi thấy rằng nó cũng đơn giản như xóa bất kỳ tệp nào khác khỏi nautilus hoặc bất kỳ trình thám hiểm tệp nào khác (sự thật là tôi chỉ thử với nautilus).

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.