[issue12350] Improve stat_result.st_blocks and st_blksize documentation
New submission from Lars Wirzenius : 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 <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 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 <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 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 <http://bugs.python.org/issue12350> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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
<http://bugs.python.org/issue21360>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
