Add the user name to the ssh command line only if it's not the same as
the local logged-in user. OpenSSH will take it as a default value
anyway, but otherwise we'll override ~/.ssh/config settings which might
be not what the user wants.
* Factored out vfs_get_local_username()
* Moved default-user detection to fish subsystem (URL_USE_ANONYMOUS)
* Slight modifications to the comments and wording
Originally from: http://mail.gnome.org/archives/mc-devel/2005-April/msg00035.html
The routines `vfs_s_find_entry_linear()' and `vfs_s_find_entry_tree()'
call `canonicalize_pathname()' on entry. This routine eats `..' path
components in certain cases. In case of ftpfs this is not desired -
the path should be kept as is since the code in direntry.c doesn't have
enough knowledge of the directory structure on the remote end.
Assume that
there is a path like this on the remote server
/path1/path2/path3
The `path2' component is a symlink to some directory and `path3' is a
symlink stored in `path2' which is relative to `path2' i.e.
path2
path3 -> ../some/other/path
Now, the code in direntry.c will determine that `path3' is a symlink and
will try to resolve (vfs_s_resolve_symlink) it by passing the following path
/path1/path2/../some/other/path
to `vfs_s_find_entry_linear' . As I've said above this routine calls
`canonicalize_pathname' on entry which will modify the path like this:
/path1/some/other/path
Now this is clearly wrong since `path2' is a symlink and it should be
resolved first. In the case of ftpfs the code in direntry.c doesn't have
enough knowledge about physycal directory layout on the remote filesystem
so it shouldn't try to canonicalize the path. The path should be left as
is and passed to the remote end for processing.
Fix issue:
Changed function canonicalize_pathname (as fact, renamed to custom_canonicalize_pathname)
In this function added ability to partial canonicalize of pathname.
And some functions from vfs/direntry.c calls custom_canonicalize_pathname without
removal of '..' stuff.
Signed-off-by: Slava Zanko <slavazanko@gmail.com>
ENTRY "example.net" URL "/#ftp:examplenet:5wDJP1B/y@example.net"
When I try connect to it I saw:
"ftpfs: making connection to examplenet"
off course this is failed by timeout.
Fix issue:
Now search for '@' sign.
If present - search for slash at found position
If not present - search at start of string.
Also fixed parce '@' sign into password area of URI.
Signed-off-by: Slava Zanko <slavazanko@gmail.com>
g_new(), g_new0(), g_malloc(), g_malloc0() and g_realloc() functions
never return NULL and call abort() on fail. So check result of these
functions is useless. g_try_new(), g_try_new0(), g_try_malloc(),
g_try_malloc0() and g_try_realloc() functions are used instead.
Some minor optimization and code formatting are also performed.
Signed-off-by: Andrew Borodin <aborodin@vmail.ru>
Fixes such warnings:
mc/src/viewer/mcviewer.h:1: Warning: the name `view.h' supplied as the second argument
in the \file statement is not an input file
mc/vfs/vfs.c:267: Warning: explicit link request to 'op' could not be resolved
mc/src/strescape.c:219: Warning: Found unknown command `\params'
mc/src/strescape.c:153: Warning: Found unknown command `\params'
mc/src/strescape.c:187: Warning: Found unknown command `\params'
mc/src/strescape.c:219: Warning: Found unknown command `\params'
mc/src/strescape.c:153: Warning: Found unknown command `\params'
mc/src/strescape.c:187: Warning: Found unknown command `\params'
mc/vfs/fish.c:33: Warning: explicit link request to 'sh' could not be resolved
mc/vfs/fish.c:33: Warning: Found unknown command `\host'
mc/vfs/ftpfs.c:43: Warning: Found unknown command `\hobit'
mc/vfs/sfs.c:26: Warning: explicit link request to 'ugz' could not be resolved
mc/vfs/vfs.c:267: Warning: explicit link request to 'op' could not be resolved
mc/vfs/vfs.c:267: Warning: explicit link request to 'op' could not be resolved
Signed-off-by: Sergei Trofimovich <slyfox@inbox.ru>
Test case:
1) Make FISH-connect to some host;
2) sort files by modification time;
3) will see older files (from previous year) as new files
For check, connect to same host and enter in command line:
ls -lt
Thanks for bugreport to Alexander Glyzov.
Fix issue:
Because first part of FISH-ls script is Perl script.
But localtime function returns dates like:
Fri Sep 18 10:40:28 2009
But in utilvfs.c is written: So both year and time is not allowed.
This commit fixed write format of date.
Signed-off-by: Slava Zanko <slavazanko@gmail.com>
Some FTP-servers don't have chmon support (or don't able to change permissions in some cases).
This commit will add "ignore_ftp_chattr_errors" section into config file.
Now default behavior: ignore FTP errors related to chmod operations.
Signed-off-by: Slava Zanko <slavazanko@gmail.com>
Problem:
a) when running ./configure, strftime() and other functions cannot be
properly detected, since autoconf generates crappy test code, which
at least fails when warnings are treated as errors (gcc: -Werror).
b) strtime() is standard since C89, so we can simply expect it to exists
(if there's *really* some acient box out there breaking mc build,
it's libc/toolchain should be fixed ;-p)
Solution:
Remove the checks for strftime() and all workarounds
For some reason, mc aborts if .cpio magic as wrong.
This trivial patch makes mc handle it gracefully.
Signed-off-by: Slava Zanko <slavazanko@gmail.com>
Test case:
* create any zip-archive (or take exists)
* run mc
* enter into archive
* try to copy any files inside archive.
Fix issue: Try to open temporarry file twice: with O_CREATE flag; and without O_CREATE and with O_TRUNC flag
Also, created extfs_chown() function for avoid chown-related warnings.
Signed-off-by: Slava Zanko <slavazanko@gmail.com>
* Increase number of reading butes by one for better analyzation of compression type.
* Add recognize lzma archive by extention.
Signed-off-by: Slava Zanko <slavazanko@gmail.com>
...or not-so-large but nevertheless
contain more than one function call,
or contain loops, or contain if's and at least one
function call, or contain largish objects on stack.
In my experience, in those cases the code size
growth is big enough to not inline stuff.
I guess some of the really big functions
are defined inline because they have, or had in the past,
just one callsite.
But for a few years gcc already does it automatically,
no need to do it by hand and risk code size explosion
when later during code evolution another callsite
is created. This optimization by hand is simply
no longer needed.
Anyway, here is the code size difference:
text data bss dec hex filename
572337 17944 177820 768101 bb865 mc.t5/.obj/src/mc
567697 17944 177820 763461 ba645 mc.t6/.obj/src/mc
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Signed-off-by: Sergei Trofimovich <slyfox@inbox.ru>
UseCase:
* rename any patch file into patch_file.lzma_tar.patch.gz for example
* try to enter into renamed file (press Enter key on a file in panel)
* You'll see error message 'sh: lzma: command not found'
Fix issue:
* Add -b key into call of 'file' utility (to avoid filename in output)
* better parse 'file -b' output
Signed-off-by: Slava Zanko <slavazanko@gmail.com>
