Tại sao không thể đặt tên cho thư mục là.


74

Tôi chỉ nhận thấy rằng không thể đặt tên một thư mục ._.- ._thay vào đó nó được đặt tên . Đôi khi, nó biến mất ngay sau khi đặt tên nhưng xuất hiện lại sau khi làm mới khung nhìn. Windows dường như có vấn đề với các dấu chấm ở cuối tên tệp - tại sao lại như vậy?


21
Đáng chú ý là bạn tình cờ phát hiện ra "hack" để bắt đầu một tên tệp bằng .Windows.
jpmc26

8
@ ThisNameBetterBeAv Available Chưa được kiểm tra, nhưng cd -- -_-có thể có thể hoạt động. Đây --là điểm đánh dấu "kết thúc tùy chọn" phổ biến.
TripeHound

13
@ ThisNameBetterBeAv Available Không, --theo cách riêng của nó " đây là sự kết thúc của các tùy chọn, coi bất kỳ điều gì bắt đầu bằng -một giá trị theo nghĩa đen ". Chỉ cần thử nghiệm: mkdir -- -_-cd -- -_-hoạt động như tôi mong đợi.
TripeHound

2
Ngoài ra, ./-_-nên làm việc là tốt.
glglgl

5
@Alexander Trong linux, vì đó dường như là nơi các bình luận đi đến, cd "-_-"shell sử dụng các trích dẫn để nhóm nhưng không coi chúng là một phần của đối số; nó có lỗi vớiinvalid option
Izkata

Câu trả lời:


123

Windows thường yêu cầu các tệp không có phần mở rộng hoặc phần mở rộng dài ít nhất một ký tự; nó không tuyệt vời với các phần mở rộng có độ dài bằng không, tức là tên tệp kết thúc bằng .. Các thư mục cũng có thể có các tiện ích mở rộng, do đó, Windows không để tên của chúng kết thúc bằng a .. Nguồn, từ bài viết mà DavidPostill liên kết :

Sử dụng dấu chấm để tách tên tệp cơ sở khỏi phần mở rộng trong tên của thư mục hoặc tệp .

(Tôi nhấn mạnh). Nếu bạn cố gắng để kết thúc một tập tin hoặc thư mục có tên với một khoảng thời gian, Windows chỉ giả sử bạn muốn không có phần mở rộng và do đó loại bỏ nó, ngay cả khi bạn tạo ra nó với mdmột dấu nhắc lệnh.

Khu vực nguy hiểm! Nếu bạn hoàn toàn muốn một tên thư mục kết thúc ., bạn sẽ cần sử dụng chuỗi ghi đè tên thô kỳ diệu \\?\. Trong một dấu nhắc lệnh, md \\?\C:\path\to\container\._.thực sự sẽ tạo một thư mục có tên ._., nhưng rất nhiều chương trình sẽ gặp vấn đề với nó, ngay cả Explorer:

._.  các vấn đề

Một thư mục như vậy chỉ có thể được xóa rdbằng \\?\tên theo sau hoặc đổi tên bằng tên ngắn (8.3, dir /x).


1
Cảm ơn bạn đã trả lời chi tiết của bạn! :) Tôi nghĩ rằng đây sẽ là một thư mục hoàn hảo để ẩn những thứ bí mật như mật khẩu bên trong nó, bởi vì bạn chỉ có thể mở thư mục nếu bạn đổi tên nó trước, và không phải ai cũng biết cách đổi tên nó.
Đen

19
@EdwardBlack nó sẽ không ngăn chặn bất cứ ai có thể đọc trao đổi ngăn xếp (và do đó thậm chí sẽ không cung cấp bảo mật chống lại em trai giả định). Tên được đặt bởi dir /xlàm cho nó khá dễ dàng, và có những lúc tên này là tiện dụng.
Chris H

11
FWIW, các công cụ dòng lệnh của Cygwin cũng có thể tạo (và thao tác) các thư mục đó trên Windows 7 mà không cần sử dụng chuỗi ma thuật.
Steve Jessop

4
@EdwardBlack Như Chris H đã đề cập, nó không bí mật lắm, vì vậy bạn không nên lưu trữ bất cứ thứ gì đặc biệt quan trọng trong một thư mục như vậy. Hơn nữa, bảo mật và bảo vệ kỹ thuật số là một vấn đề đã được giải quyết nhiều lần. Bạn có thể sử dụng bất kỳ số phương thức và chương trình mã hóa nào để giữ mọi thứ an toàn mà không cần dựa vào tên thư mục tối nghĩa.
Kris Harper

3
Nitpick: Ít nhất là trong 8,3 ngày (tôi chưa điều tra những gì được ghi vào đĩa trên NTFS), khoảng thời gian đầu tiên không bao giờ được ghi vào đĩa. Tên được chia thành tên và phần mở rộng, chúng được lưu trữ riêng. Khi đọc nó đã lấy tên và nếu có phần mở rộng thêm thời gian và phần mở rộng cho tên. Do đó, không có cách nào để diễn đạt ._. trong cấu trúc thư mục, tất nhiên bạn bị mất dấu chấm.
Loren Pechtel

22

Windows dường như có vấn đề với các dấu chấm ở cuối tên tệp? Tại sao lại thế này?

Không kết thúc tên tệp hoặc thư mục bằng dấu cách hoặc dấu chấm. Mặc dù hệ thống tệp bên dưới có thể hỗ trợ các tên như vậy, nhưng Windows shell và giao diện người dùng thì không.

Liên kết nguồn dưới đây đi vào chi tiết hơn về các quy tắc đặt tên.

Nguồn đặt tên tệp, đường dẫn và không gian tên


5
Điều này vẫn có vẻ như lỗi với tôi.
ralu

@ralu Nếu đó là một lỗi thì MS dường như hoàn toàn không quan tâm đến việc sửa nó. Những hạn chế đó đã có từ Windows XP (nếu không sớm hơn).
DavidPostill

Windows XP? Tôi đoán là những hạn chế này có nguồn gốc từ MS-DOS 0.x - hãy yêu cầu ông Gates giải quyết vấn đề này ...
Christian Severin

17

Nó không phải là một lỗi. Đó là do thiết kế để ngăn chặn các vấn đề tương thích.
Nó là một phần còn lại từ thời DOS cũ.

Các hệ thống tệp FAT12 (đĩa mềm) và FAT16 (FAT16 trước hỗ trợ tên tệp dài được giới thiệu trong Windows 95) chỉ có tên tệp được lưu trữ trong 11 byte:
8 byte cho tên, 3 cho phần mở rộng. "Khoảng thời gian" giữa tên và phần mở rộng thậm chí không được lưu trữ. Nó được ngụ ý và tự động thêm vào cho mục đích hiển thị.
Thư mục không có phần mở rộng nào cả. Thay vào đó, 3 byte cho phần mở rộng chứa đầy các ký tự "$" (không hợp lệ trong tên thật).
Bởi vì Windows vẫn tương thích với Explorer này và nhiều thành phần khác của Windows âm thầm làm cho khoảng thời gian theo dõi biến mất để tránh tạo ra các vấn đề tương thích.
Như những người khác đã tuyên bố, bạn thực sự có thể xử lý các thư mục như vậy bằng cách sử dụng ngữ nghĩa RAW (\? \ Tiền tố trước tên đường dẫn tuyệt đối).
Đằng sau hậu trường, NTFS và các hệ thống tệp mạng không có vấn đề gì với các tệp và thư mục đó. Đây chỉ là một trường hợp Explorer cố gắng ngăn người dùng tạo ra thứ gì đó có thể gây ra sự cố cho phần mềm khác.

(Trên thực tế cũng có một số phần còn lại khác:
Các tên tệp như COM, COM1, COM2, AUX, PRN, LPT, LPT1, LPT2, LPT3, CON có thể gây ra sự cố tương tự trong đó Explorer và nhiều phần Windows khác bị lẫn lộn bởi vì những tên này là những cái tên "dành riêng" có từ thời DOS.)


3
Đối với bất kỳ độc giả nào khác ban đầu nghi ngờ về dấu chấm không được lưu trữ: điều đó đúng với CP / M và tất cả các phiên bản của FAT, bao gồm cả FAT16FAT32 .
Ben N

1
Tôi nhớ một số chương trình DOS cũ (chạy trên DOS thực tế, có thể sử dụng trực tiếp các hàm INT13) mang lại cho tôi sự đau buồn thực sự bằng cách nào đó quản lý để tạo một tệp có tên: foo.bar trên c: drive ...
rackandboneman

2
@BenN: thật ra, trên FAT32 thì hơi khác một chút; nó lưu trữ cả tên tệp ngắn (8 + 3 byte với tên tương thích ngược "dấu chấm ẩn"), cộng với tên tệp dài (được gọi là LFN), được tạo thành tối đa 255 ký tự UCS-2 có dấu chấm rõ ràng và trừ khi bạn đang làm việc với các ứng dụng 16 bit, bạn luôn làm việc với LFN.
Matteo Italia

1
@MatteoItalia Theo hiểu biết của tôi thì tên tệp dài được giữ trong các mục nhập giả; Các bản cài đặt Windows đang tìm kiếm cho các mục này và hiển thị chúng thay vì SFN nếu có thể. Xem bài đăng của Raymond Chen về chủ đề này , hoặc phần VFAT của thông số định dạng FAT32 mà tôi đã liên kết ở trên.
Ben N

1
-1 bạn sai về phần mở rộng thư mục; có thể đúng với CP / M (bộ nhớ của tôi rất tệ về hệ điều hành đó), nhưng tôi đã sử dụng thư mục "programm.ing" trong cây của tôi kể từ thời DOS và xem win.tue.nl/~aeb/linux/ fs / fat / fat-1.html - các mục trong thư mục được xử lý chính xác như các tệp, chúng cũng có thể có tên 8.3. Kiểm tra: tạo thư mục 8.3 ( mkdir testfile.name) và hiển thị tên DOS của nó trong Windows ( dir /x) - bạn sẽ nhận được TESTFI~1.NAM, như mong đợi.
vaxquis

3

Vấn đề ở đây là Windows (DOS) cho phép đặt tên tệp 8.3 trên các hệ thống tệp FAT. Ý nghĩa, 8 ký tự, theo sau là a. theo sau là ba nhân vật. Unix và Linux cho phép mọi ký tự, ngoại trừ / và \ 0. \ 0 là dấu kết thúc chuỗi ký tự C và / là dấu phân cách thư mục. Mọi thứ khác có thể được sử dụng.

Windows 95 đã khắc phục vấn đề này bằng cách duy trì cơ sở dữ liệu tên tệp ngắn (8.3) thành siêu dữ liệu Tên tệp dài (LFN). Nếu bạn xóa các tệp HĐH Windows 95, bạn sẽ bị bỏ lại các tệp có tên kỳ lạ trên đĩa trong lần cài đặt Windows 95 tiếp theo. Ví dụ: "Tài liệu của tôi" có thể được đặt tên MYDOCU ~ 1 trên đĩa. Rõ ràng, nếu bạn mất dữ liệu meta, bạn không thể dễ dàng chuyển đổi chúng.

Shell phải đối phó với nhiều bước tiến lịch sử tồn tại từ thời MS-DOS.

Hi vọng điêu nay co ich


1
Thực sự không có cơ sở dữ liệu nào cả; Windows chỉ kẹt các phần của tên tệp dài vào đĩa dưới dạng tệp giả. Xem bài viết của Raymond Chen về chủ đề này .
Ben N
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.