Changes between Initial Version and Version 4 of Ticket #13


Ignore:
Timestamp:
01/11/14 15:38:28 (11 years ago)
Author:
ossi
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #13

    • Property Reporter changed from slavazanko to zlatk0
    • Property Version changed from to 4.6.1
    • Property Branch state changed from to no branch
    • Property Milestone changed from to Future Releases
    • Property Severity changed from to no branch

  • Ticket #13 – Description

    initial v4  
    77||Release:||current (CVS or snapshot)||Operating System:||All|| 
    88 
    9 Discussion: 
    10 {{{ 
    11 Thu 30 Mar 2006 12:57:52 PM UTC, comment #14: 
    12  
    13 Reopening this one. I'll revert the patch since it breaks fish. Once 
    14 I fix this breakage I'll commit it again. 
    15         Pavel Tsekov <ptsekov> 
    16 Project AdministratorIn charge of this item. 
    17 Thu 23 Mar 2006 12:37:47 PM UTC, comment #13: 
    18  
    19 I've commited the patch. Closing the bugreport as fixed. 
    20         Pavel Tsekov <ptsekov> 
    21 Project AdministratorIn charge of this item. 
    22 Thu 09 Mar 2006 08:48:55 AM UTC, comment #12: 
    23  
    24 I'll wait till 21 March before commiting this patch. That's almost  
    25 two weeks - I think this is enough time for other developers to  
    26 comment. 
    27         Pavel Tsekov <ptsekov> 
    28 Project AdministratorIn charge of this item. 
    29 Thu 09 Mar 2006 12:15:01 AM UTC, comment #11: 
    30  
    31 Yes, both moving and copying a single file works fine now (latest  
    32 CVS with the attached patch applied), even with  
    33 ftpfs_first_cd_then_ls=0. Again, thanks a lot! :-) 
    34         Thomas Zajic <ZlatkO> 
    35 Project Member 
    36 Wed 08 Mar 2006 03:02:04 PM UTC, comment #10: 
    37  
    38 If it is not clear you still should apply the patch attached to this 
    39 bugreport since I haven't commited that yet. 
    40         Pavel Tsekov <ptsekov> 
    41 Project AdministratorIn charge of this item. 
    42 Wed 08 Mar 2006 03:00:47 PM UTC, comment #9: 
    43  
    44 I've just checked in a patch which improves ftpfs_dir_load(). It  
    45 enables the attached patch to work no matter whether  
    46 `ftpfs_first_cd_then_ls' is set or not. So if you checkout the  
    47 source from cvs it should work. 
    48         Pavel Tsekov <ptsekov> 
    49 Project AdministratorIn charge of this item. 
    50 Mon 06 Mar 2006 08:35:11 AM UTC, comment #8: 
    51  
    52 ftpfs_first_cd_then_ls set to 0 is unreliable. In fact  
    53 ftpfs_first_cd_then_ls is set by default for some time now. Of  
    54 course I should have mentioned that :( Anyway I'll see why the patch 
    55 breaks the old behaviour when ftpfs_first_cd_then_ls is unset. 
    56         Pavel Tsekov <ptsekov> 
    57 Project AdministratorIn charge of this item. 
    58 Fri 24 Feb 2006 06:47:08 AM UTC, comment #7: 
    59  
    60 UPDATE: I just found out that the patch does indeed fix the problem  
    61 for both vanilla 4.6.1 and 4.6.1a-CVS, if I also change  
    62 "ftpfs_first_cd_then_ls" from "0" to "1" in ~/.mc/ini. This is an  
    63 acceptable solution for me, so as far as I'm concerned, feel free to 
    64  commit the patch and mark this bug fixed. 
    65  
    66 Thanks a lot! :-) 
    67         Thomas Zajic <ZlatkO> 
    68 Project Member 
    69 Fri 24 Feb 2006 06:31:35 AM UTC, comment #6: 
    70  
     9Original submission: 
     10{{{ 
     11Originally sent to mc-devel[1]: 
     12 
     13--- BEGIN ORIGINAL MESSAGE --- 
     14When moving/copying a single file to an FTP VFS where I only have  
     15execute permission on the parent directory (ie. no read and write),  
     16I have to add a trailing slash ("/") to the target specification  
     17manually, or else I get a "Permission denied" from the FTP server.  
     18Copying/moving multiple files works fine. 
     19 
     20This might be some sort of special case, actually. Here's the file  
     21hierarchy and permission details: 
     22 
     23[root blah]:/home/ftp/blahftp# ls -la 
     24total 32 
     25drwxrwx--x 4 root ftp 4096 Jan 13 15:56 . 
     26drwxr-xr-x 9 root root 4096 Oct 5 18:09 .. 
     27drwxrwxrwx 2 ftp ftp 20480 Jan 15 14:18 hidden_dir_1 
     28drwxrwxrwx 2 ftp ftp 4096 Dec 19 16:50 hidden_dir_2 
     29[...] 
     30[root blah]:/home/ftp/blahftp# 
     31 
     32The net effect of this is that you have full access to the  
     33hidden_dirs, but you have to know its name. If you log on to the FTP 
     34server's root, it appears empty, and you're not allowed to upload  
     35files or create directories there (yes, I'm aware that this is  
     36security by obscurity, thank you very much ;-). 
     37 
     38Coming back to the problem at hand, when I want to copy/move a  
     39single file to hidden_dir_2 (ie. the target specification in the  
     40copy/move dialog box is  
     41"/#ftp:ftp.security-by-obscurity.net/hidden_dir_2"), I get  
     42"Permission denied". If I manually add a trailing slash (ie. target  
     43specification "/#ftp:ftp.security-by-obscurity.net/hidden_dir_2/"),  
     44it works fine. Copying/moving multiple files also works fine even  
     45without a trailing slash, somehow mc seems to automagically do the  
     46right thing in this case. 
     47 
     48It's not a big problem, to be honest, but merely a minor annoyance. 
     49--- END ORIGINAL MESSAGE --- 
     50 
     51This bug is still present as of mc-4.6.1-pre4a. Just adding this to  
     52Savannah to make sure it's not forgotten. 
     53 
     54[1] http://mail.gnome.org/archives/mc-devel/2005-January/msg00020.html  
     55}}} 
     56 
     57Comment 1 by Pavel Tsekov <ptsekov> at Fri 17 Feb 2006 01:18:56 PM UTC: 
     58{{{ 
     59MC maintains an internal representation of the remote end's  
     60directory structure and it is used by calls such as stat(). 
     61In the described setup MC is unable to determine that  
     62hidden_dir_[12] actually exist because listing the parent directory  
     63yields no entries. As a result it doesn't have entries for  
     64hidden_dir_[12] in its internal cache and subsequent calls to stat() 
     65with those directory names fail and MC cannot determine that they  
     66are directories. I'll try to find the best way to fix this. 
     67}}} 
     68 
     69Comment 2 by Pavel Tsekov <ptsekov> at Tue 21 Feb 2006 03:10:14 PM UTC: 
     70{{{ 
     71Please, test the attached patch. It is a simple one-liner. I think  
     72this is the right way to solve the described issue, however I'll not 
     73commit without the agreement of other developers. 
     74 
     75Andrew, please, comment if possible. 
     76}}} 
     77 
     78Comment 3 by Pavel Tsekov <ptsekov> at Tue 21 Feb 2006 03:11:19 PM UTC: 
     79{{{ 
     80I forgot to attach the patch, so here it comes. 
     81}}} 
     82 
     83Comment 4 by Thomas Zajic <ZlatkO> at Thu 23 Feb 2006 07:00:36 AM UTC: 
     84{{{ 
     85The patch doesn't seem to fix the problem for me, I'm afraid.  
     86Actually, also the workaround of adding a trailing "/" slash  
     87manually doesn't work anymore now. 
     88 
     89Instead of "Permission denied", I now get "Cannot overwrite  
     90directory  
     91"/#ftp:ftp.security-by-obscurity.net/hidden_dir_2/testfile" -  
     92Success (0), [ Skip ] [ Retry ] [ Abort ]" in both cases (ie. with  
     93and without adding a trailing "/" manually), for both copying and  
     94moving a single file ("testfile"). Moreover, copying/moving multiple 
     95files now also doesn't work anymore, both with and without adding a  
     96trailing "/" manually, showing the same error message. 
     97 
     98Just in case this matters, while mc displays the error dialog, the  
     99destination panel shows "ftpfs: failed; nowhere to fallback to" in  
     100the top line where it normally shows the directory name. I don't  
     101think that's significant, though, as it also shows the same without  
     102the patch applied, but still copies/moves the file(s) properly. 
     103 
     104BTW I applied your patch to the plain vanilla 4.6.1 tarball from  
     105ibiblio.org - should I be using a CVS version instead? 
     106}}} 
     107 
     108Comment 5 by Pavel Tsekov <ptsekov> at Thu 23 Feb 2006 08:24:48 AM UTC: 
     109{{{ 
     110The patch is against MC from CVS - sorry, that I didn't mention it.  
     111Please, test with CVS version of MC. If this is not an option,  
     112please, let me know and I'll give MC 4.6.1 a try. 
     113}}} 
     114 
     115Comment 6 by Thomas Zajic <ZlatkO> at Fri 24 Feb 2006 06:31:35 AM UTC: 
     116{{{ 
    71117Tested with today's CVS version (20060224), same problem. Here's the 
    72118FTP server's log from that session, trying to copy/move testfile1,  
    … …  
    106152difference, except that the log file shows "PORT" commands where it  
    107153shows "PASV" above. 
    108         Thomas Zajic <ZlatkO> 
    109 Project Member 
    110 Thu 23 Feb 2006 08:24:48 AM UTC, comment #5: 
    111  
    112 The patch is against MC from CVS - sorry, that I didn't mention it.  
    113 Please, test with CVS version of MC. If this is not an option,  
    114 please, let me know and I'll give MC 4.6.1 a try. 
    115         Pavel Tsekov <ptsekov> 
    116 Project AdministratorIn charge of this item. 
    117 Thu 23 Feb 2006 07:00:36 AM UTC, comment #4: 
    118  
    119 The patch doesn't seem to fix the problem for me, I'm afraid.  
    120 Actually, also the workaround of adding a trailing "/" slash  
    121 manually doesn't work anymore now. 
    122  
    123 Instead of "Permission denied", I now get "Cannot overwrite  
    124 directory  
    125 "/#ftp:ftp.security-by-obscurity.net/hidden_dir_2/testfile" -  
    126 Success (0), [ Skip ] [ Retry ] [ Abort ]" in both cases (ie. with  
    127 and without adding a trailing "/" manually), for both copying and  
    128 moving a single file ("testfile"). Moreover, copying/moving multiple 
    129 files now also doesn't work anymore, both with and without adding a  
    130 trailing "/" manually, showing the same error message. 
    131  
    132 Just in case this matters, while mc displays the error dialog, the  
    133 destination panel shows "ftpfs: failed; nowhere to fallback to" in  
    134 the top line where it normally shows the directory name. I don't  
    135 think that's significant, though, as it also shows the same without  
    136 the patch applied, but still copies/moves the file(s) properly. 
    137  
    138 BTW I applied your patch to the plain vanilla 4.6.1 tarball from  
    139 ibiblio.org - should I be using a CVS version instead? 
    140         Thomas Zajic <ZlatkO> 
    141 Project Member 
    142 Tue 21 Feb 2006 03:11:19 PM UTC, comment #3: 
    143  
    144 I forgot to attach the patch, so here it comes. 
    145         Pavel Tsekov <ptsekov> 
    146 Project AdministratorIn charge of this item. 
    147 Tue 21 Feb 2006 03:10:14 PM UTC, comment #2: 
    148  
    149 Please, test the attached patch. It is a simple one-liner. I think  
    150 this is the right way to solve the described issue, however I'll not 
    151 commit without the agreement of other developers. 
    152  
    153 Andrew, please, comment if possible. 
    154         Pavel Tsekov <ptsekov> 
    155 Project AdministratorIn charge of this item. 
    156 Fri 17 Feb 2006 01:18:56 PM UTC, comment #1: 
    157  
    158 MC maintains an internal representation of the remote end's  
    159 directory structure and it is used by calls such as stat(). 
    160 In the described setup MC is unable to determine that  
    161 hidden_dir_[12] actually exist because listing the parent directory  
    162 yields no entries. As a result it doesn't have entries for  
    163 hidden_dir_[12] in its internal cache and subsequent calls to stat() 
    164 with those directory names fail and MC cannot determine that they  
    165 are directories. I'll try to find the best way to fix this. 
    166         Pavel Tsekov <ptsekov> 
    167 Project AdministratorIn charge of this item. 
    168 Mon 16 May 2005 05:14:00 PM UTC, original submission: 
    169  
    170 Originally sent to mc-devel[1]: 
    171  
    172 --- BEGIN ORIGINAL MESSAGE --- 
    173 When moving/copying a single file to an FTP VFS where I only have  
    174 execute permission on the parent directory (ie. no read and write),  
    175 I have to add a trailing slash ("/") to the target specification  
    176 manually, or else I get a "Permission denied" from the FTP server.  
    177 Copying/moving multiple files works fine. 
    178  
    179 This might be some sort of special case, actually. Here's the file  
    180 hierarchy and permission details: 
    181  
    182 [root blah]:/home/ftp/blahftp# ls -la 
    183 total 32 
    184 drwxrwx--x 4 root ftp 4096 Jan 13 15:56 . 
    185 drwxr-xr-x 9 root root 4096 Oct 5 18:09 .. 
    186 drwxrwxrwx 2 ftp ftp 20480 Jan 15 14:18 hidden_dir_1 
    187 drwxrwxrwx 2 ftp ftp 4096 Dec 19 16:50 hidden_dir_2 
    188 [...] 
    189 [root blah]:/home/ftp/blahftp# 
    190  
    191 The net effect of this is that you have full access to the  
    192 hidden_dirs, but you have to know its name. If you log on to the FTP 
    193 server's root, it appears empty, and you're not allowed to upload  
    194 files or create directories there (yes, I'm aware that this is  
    195 security by obscurity, thank you very much ;-). 
    196  
    197 Coming back to the problem at hand, when I want to copy/move a  
    198 single file to hidden_dir_2 (ie. the target specification in the  
    199 copy/move dialog box is  
    200 "/#ftp:ftp.security-by-obscurity.net/hidden_dir_2"), I get  
    201 "Permission denied". If I manually add a trailing slash (ie. target  
    202 specification "/#ftp:ftp.security-by-obscurity.net/hidden_dir_2/"),  
    203 it works fine. Copying/moving multiple files also works fine even  
    204 without a trailing slash, somehow mc seems to automagically do the  
    205 right thing in this case. 
    206  
    207 It's not a big problem, to be honest, but merely a minor annoyance. 
    208 --- END ORIGINAL MESSAGE --- 
    209  
    210 This bug is still present as of mc-4.6.1-pre4a. Just adding this to  
    211 Savannah to make sure it's not forgotten. 
    212  
    213 [1] http://mail.gnome.org/archives/mc-devel/2005-January/msg00020.html  
    214 }}} 
     154}}} 
     155 
     156Comment 7 by Thomas Zajic <ZlatkO> at Fri 24 Feb 2006 06:47:08 AM UTC: 
     157{{{ 
     158UPDATE: I just found out that the patch does indeed fix the problem  
     159for both vanilla 4.6.1 and 4.6.1a-CVS, if I also change  
     160"ftpfs_first_cd_then_ls" from "0" to "1" in ~/.mc/ini. This is an  
     161acceptable solution for me, so as far as I'm concerned, feel free to 
     162 commit the patch and mark this bug fixed. 
     163 
     164Thanks a lot! :-) 
     165}}} 
     166 
     167Comment 8 by Pavel Tsekov <ptsekov> at Mon 06 Mar 2006 08:35:11 AM UTC: 
     168{{{ 
     169ftpfs_first_cd_then_ls set to 0 is unreliable. In fact  
     170ftpfs_first_cd_then_ls is set by default for some time now. Of  
     171course I should have mentioned that :( Anyway I'll see why the patch 
     172breaks the old behaviour when ftpfs_first_cd_then_ls is unset. 
     173}}} 
     174 
     175Comment 9 by Pavel Tsekov <ptsekov> at Wed 08 Mar 2006 03:00:47 PM UTC: 
     176{{{ 
     177I've just checked in a patch which improves ftpfs_dir_load(). It  
     178enables the attached patch to work no matter whether  
     179`ftpfs_first_cd_then_ls' is set or not. So if you checkout the  
     180source from cvs it should work. 
     181}}} 
     182 
     183Comment 10 by Pavel Tsekov <ptsekov> at Wed 08 Mar 2006 03:02:04 PM UTC: 
     184{{{ 
     185If it is not clear you still should apply the patch attached to this 
     186bugreport since I haven't commited that yet. 
     187}}} 
     188 
     189Comment 11 by Thomas Zajic <ZlatkO> at Thu 09 Mar 2006 12:15:01 AM UTC: 
     190{{{ 
     191Yes, both moving and copying a single file works fine now (latest  
     192CVS with the attached patch applied), even with  
     193ftpfs_first_cd_then_ls=0. Again, thanks a lot! :-) 
     194}}} 
     195 
     196Comment 12 by Pavel Tsekov <ptsekov> at Thu 09 Mar 2006 08:48:55 AM UTC: 
     197{{{ 
     198I'll wait till 21 March before commiting this patch. That's almost  
     199two weeks - I think this is enough time for other developers to  
     200comment. 
     201}}} 
     202 
     203Comment 13 by Pavel Tsekov <ptsekov> at Thu 23 Mar 2006 12:37:47 PM UTC: 
     204{{{ 
     205I've commited the patch. Closing the bugreport as fixed. 
     206}}} 
     207 
     208Comment 14 by Pavel Tsekov <ptsekov> at Thu 30 Mar 2006 12:57:52 PM UTC: 
     209{{{ 
     210Reopening this one. I'll revert the patch since it breaks fish. Once 
     211I fix this breakage I'll commit it again. 
     212}}}