Hello, Peter!
> your message surprises me: to my knowledge the mailfs that is
> distributed with mc doesn't even work with current versions of
> the "Midnight Commander" (the script used to return the number of
> lines in the message as the "file size". Starting with 4.5.x, mc
> takes that "file size" serious and only displays that many bytes
That't true for the editor, but not for the viewer. I don't think you want
to edit your mail, so "doesn't even work" is exaggerated, but it should be
fixed, I agree.
> - has this changed again?). Already in October 1999, I had posted
> some patches to fix this and some other things (like providing a
> fallback date ;-) to thist list and asked, that somebody with CVS
> write access apply these patches, which never happened. In case
> somebody is still interested, I attach the "mailfs", that I am
> currently using below.
I'm sorry for your frustration. Unfortunately, there are too few active
developers here to consider every patch. Your chances will grow if you
include ChangeLog entries.
> As far as the date parsing is concerned, I personally don't think
> that trying to parse all date formats out there would be a good
> idea - there are just too many variations. To get this right
> would require much more code than the whole rest of the script.
> The regex for date parsing in my script was only intended as a
> last ressort - if available, the Date::Parse module will be used
> instead (which does a much better - but still not perfect - job
> parsing "exotic" date formats).
I don't agree. The messages must follow the standard. The must use
RFC-compliant standards. The standard doesn't allow japanese format or
french names for months.
All the discrepancies are bugs, and I don't expect too many bugs in
addition to those that I have already taken care of.
By the way, I just realized that yeat "99" will be interperted as 2099. I
guess I'll have to implement year windowing.
> By the way, there also is a little bug in vfs.c, that causes mc
> to display an incorrect year number when an extfs lists filedates
> in ctime format. An (admittedly ugly) patch is included below.
Even a short explanation would help. I have no time to investigate your
patch in the debugger.
Actually, could you make a test case? I mean a listing that would
demonstrate the problem.
For example, this file (we'll call it test1):
-rwxr--r-- 1 500 0 0 Dec 14 2000 13:58 test
-rw-r--r-- 1 500 0 273 Dec 14 2000 02:12 test/foo/bar
will crash mc if I do
cd test1#lslR
(but it's another story). I mean, the lslR filesystem is very convenient
for creating such test cases.
Regards,
Pavel Roskin
