[PATCH] Re: Issues to fix before 4.6.1?
Hello Oswald,
On Tue, 2005-03-29 at 22:37 +0200, Oswald Buddenhagen wrote:
On Tue, Mar 29, 2005 at 05:46:33PM +0200, Jindrich Novy wrote:
On Tue, 2005-03-29 at 11:07 +0300, Andrew V. Samoilov wrote:
There is a data loss possible if file is edited with external editor over
VFS.
I have similar experience even with mcedit without VFS - data loss when
disk quota is exceeded, the edited file is truncated to zero size. I had
these problems with mc-4.5.51 so I'm not sure if it's still a problem
with recent mc.
i've had this just yesterday ... good luck it was no important file.
this happens with the quick save mode ... it must, given the way it
works. not sure it can be fixed properly at all without just switching
to another mode. oh, well, it could be fixed to not lose data, but the
resulting file would be a bit inconsistent.
Seems like mc still tests presence of a file on local filesystem in
rather brutal way when quick-saving:
if (!vfs_file_is_local (filename) ||
(fd = mc_open (filename, O_WRONLY | O_BINARY)) == -1)
what actually truncates the filename to zero size. The proposed patch
modifies the opening mode to O_RDONLY so that we shouldn't lose any data
at this point.
Furthermore I noticed ctype.h is #included redundantly twice in
edit_cmd.c. This fixes the second patch.
Jindrich
--
Jindrich Novy [EMAIL PROTECTED], http://people.redhat.com/jnovy/
--- mc/edit/editcmd.c.dontrewrite 2005-03-17 22:18:23.0 +0100
+++ mc/edit/editcmd.c 2005-03-30 09:28:25.076282176 +0200
@@ -240,7 +240,7 @@ edit_save_file (WEdit *edit, const char
}
if (!vfs_file_is_local (filename) ||
- (fd = mc_open (filename, O_WRONLY | O_BINARY)) == -1) {
+ (fd = mc_open (filename, O_RDONLY | O_BINARY)) == -1) {
/*
* The file does not exists yet, so no safe save or
* backup are necessary.
--- mc/edit/editcmd.c.ctype 2005-03-17 22:18:23.0 +0100
+++ mc/edit/editcmd.c 2005-03-30 10:05:48.983156480 +0200
@@ -24,7 +24,6 @@
/* #define PIPE_BLOCKS_SO_READ_BYTE_BY_BYTE */
#include config.h
-#include ctype.h
#include stdio.h
#include stdarg.h
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Fw: Re: Xterm window title enhancement to hostname:/path II.
Hello Pavel, On Wed, 2005-03-23 at 17:06 +0100, Pavel Vvra wrote: What do you think about restoring of original title when mc ends? I usually open xterm with some title, then I run ssh client and then I run commander. When I run mc, title of window is changed, but when I exit mc last used title is still displayed as permanent title. Unfortunately I cannot reproduce your case. I see the xterm title correctly restored after I quit mc even if I ssh somewhere and launch mc there. Did I miss something? (using the latest CVS mc) Jindrich -- Jindrich Novy [EMAIL PROTECTED], http://people.redhat.com/jnovy/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Re: Issues to fix before 4.6.1?
On Wed, Mar 30, 2005 at 10:11:19AM +0200, Jindrich Novy wrote: if (!vfs_file_is_local (filename) || (fd = mc_open (filename, O_WRONLY | O_BINARY)) == -1) what actually truncates the filename to zero size. it does not, unless mc_open has totally misleading semantics - there is no O_TRUNCATE. the truncation comes during the actual write ... which leaves us with a truncated/empty file, if we run out-of-space in the middle. the solution would be not to use O_TRUNCATE at all. instead, first write the part that extends beyond the end of the old file. if that fails to complete, truncate to the old length. if we crash now, the old file will have garbage appended, but at least it's not clobbered alltogether. note that we cannot just seek to the new end and write one byte because of sparse files. after the extension was written, overwrite the start of the file with the new content and possibly truncate the file to the new length. this is all sooo ugly ... -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Debian bug list (#241891)
Yes but if you read the end of the bug report, Dmitry Rutsky says that if you replace 'posix_openpt' by 'getpt' it works. So couldn't we change the order of preference ? A warning for BSD pseudo terminal users http://lwn.net/Articles/70487/#Comments http://www.ussg.iu.edu/hypermail/linux/kernel/0402.1/0655.html I really do not know if bsd pty will be removed or not but it is a point against moving to bsd first. http://www.ussg.iu.edu/hypermail/linux/kernel/0402.1/0552.html Using BSD ptys is a security hazard. They should *definitely* not be usef preferentially. On my system (RH9) they aren't used by telnet even though they exist. -hpa I suggest one keep posix first. Ciao Alban ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Savannah bug #12406: /usr/share/mc/extfs/uarj bug
Sorry, forgot the direct link :( http://savannah.gnu.org/bugs/?func=detailitemitem_id=12406 On Wed, 23 Mar 2005, Pavel Tsekov wrote: Hello, The original reporter describes what could be a possible fix for this issue. Any extfs guru caring to check that one ? ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
