[issue21360] mailbox.Maildir should ignore files named with a leading dot
New submission from Lars Wirzenius: The maildir format specification (see http://cr.yp.to/proto/maildir.html) is clear that files named with leading dots should be ignore: Unless you're writing messages to a maildir, the format of a unique name is none of your business. A unique name can be anything that doesn't contain a colon (or slash) and doesn't start with a dot. Do not try to extract information from unique names. Test case: liw@havelock$ find Maildir -ls 89212064 drwxrwxr-x 5 liw liw 4096 Apr 26 23:03 Maildir 89212074 drwxrwxr-x 2 liw liw 4096 Apr 26 23:03 Maildir/cur 89212094 drwxrwxr-x 2 liw liw 4096 Apr 26 23:03 Maildir/tmp 89212084 drwxrwxr-x 2 liw liw 4096 Apr 26 23:03 Maildir/new 89135230 -rw-rw-r-- 1 liw liw 0 Apr 26 23:03 Maildir/new/.foo liw@havelock$ python -c 'import mailbox maildir = mailbox.Maildir(Maildir) print maildir.keys() ' ['.foo'] liw@havelock$ The correct output would be the empty list. mutt -f Maildir correctly shows now messages in that folder. -- components: Library (Lib) messages: 217221 nosy: liw priority: normal severity: normal status: open title: mailbox.Maildir should ignore files named with a leading dot type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21360 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12350] Improve stat_result.st_blocks and st_blksize documentation
Lars Wirzenius l...@liw.fi added the comment: Right. So I guess at least the following should be changed (I'll make an actual patch once there's consensus): * st_blocks should say that the size of block is often 512 bytes, but that's not guaranteed, and there's no way to know for sure * st_blksize should say it is size of efficient I/O, and is unrelated to st_blocks Should there be something more? Ideally, there should be a way to find out the size of blocks for st_blocks, but I don't know how to figure that out (though probably code from GNU's du could be borrowed). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12350 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12350] Improve stat_result.st_blocks and st_blksize documentation
New submission from Lars Wirzenius l...@liw.fi: Attached patch adds a few words to the os.stat documentation for the st_blocks and st_blksize fields to clarify them. -- assignee: docs@python components: Documentation files: stat_result.patch keywords: patch messages: 138467 nosy: docs@python, liw priority: normal severity: normal status: open title: Improve stat_result.st_blocks and st_blksize documentation versions: Python 2.7 Added file: http://bugs.python.org/file22382/stat_result.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12350 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12350] Improve stat_result.st_blocks and st_blksize documentation
Lars Wirzenius l...@liw.fi added the comment: http://pubs.opengroup.org/onlinepubs/009695399/basedefs/sys/stat.h.html says A file system-specific preferred I/O block size for this object. In some file system types, this may vary from file to file., which says essentially the same as the Linux stat(2) manpage from which I copied the extra words. The same page claims that st_blocks may use other units than 512 byte blocks, but that seems to be quite rare. GNU coreutils sources claim HP-UX and AIX PS/2 have non-512 blocks. Perhaps it would be better to indicate how to find out the block size? (Since st_blksize is not it, but that's an easy assumption to make.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12350 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
