Random832 <random...@fastmail.com>: > On Fri, Mar 18, 2016, at 20:55, Chris Angelico wrote: >> On Sat, Mar 19, 2016 at 9:03 AM, Marko Rauhamaa <ma...@pacujo.net> wrote: >> > Also, special-casing '\0' and '/' is >> > lame. Why can't I have "Results 1/2016" as a filename? >> >> Would you be allowed to have a directory named "Results 1" as well? > > If I were designing a new operating from scratch and didn't have to be > compatible with anything, I would probably have pathnames be tuples of > strings (maybe represented at the low level with percent-escaping), > rather than having a directory separator.
Speaking of the low level, the classic UNIX file system doesn't make use of pathnames. Rather, the files are nameless. They are identified by the device (= file system) number plus the inode number. Some files are directories, dir objects if you will, that map filenames to inode numbers. The file system enforces the limitation that the filenames (directory keys) cannot contain '\0' or '/' ASCII characters. The entries of the directory are called (hard) links. A pathname is a clumsy proxy for a file because the file system may be modified between references through renames or deletions. What you'd want is reference object that maintains a reference count on the inode. Or course, you could create a hard link on the fly, but the operating system doesn't clear the link automatically when the client process goes away nor does it prevent other processes from tampering with the link. You could open the file and use the file descriptor as such a reference object. However, the process may not have access rights to open the file. UNIX forces you to open a file with O_RDONLY, O_WRONLY or O_RDWR; you'd need an O_REF option that doesn't allow you any I/O access to the file but allows you to refer to a file. Marko -- https://mail.python.org/mailman/listinfo/python-list
