Fwd: Re: Subject: Inquiry About Samba VFS Feature in Midnight Commander

--===============4600988737513457203==
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_9B5B9CCD-6052-49F8-A668-20CD271558E4"


--Apple-Mail=_9B5B9CCD-6052-49F8-A668-20CD271558E4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Lol, wrong list :-/

> Begin forwarded message:
>=20
> From: "Yury V. Zaytsev" <[email protected]>
> Subject: Re: Subject: Inquiry About Samba VFS Feature in Midnight =
Commander
> Date: 19. January 2025 at 11:06:35 GMT+1
> To: Daphne Susan Saju <daphne.saju-nc6IDEaYbZfbFSlKd4bkJ/d9D2ou9A/[email protected]>
> Cc: Andrew Borodin <[email protected]>, [email protected]
>=20
>=20
> Hi Daphne,
>=20
> I=E2=80=99m putting the mc-devel@ on CC, since I think that =
discussions on this topic do belong there and might be of interest for a =
wider audience.
>=20
> I have a few comments in addition to what Andrew said, which will =
hopefully be of some help:
>=20
>> On 19. Jan 2025, at 09:46, Andrew Borodin <[email protected]> wrote:
>>=20
>>> 1.  The primary reasons behind the decision to remove this =
feature=E2=80=94were there
>>> specific technical challenges, security concerns, or maintainability =
issues?
>>=20
>> The primary reason is a bundled ancient Samba code.
>> Please see https://midnight-commander.org/ticket/1 and related =
tickets for details.
>=20
> Just to expand on that a little bit:
>=20
> Early versions of Samba weren=E2=80=99t built in a modular way (there =
was no libsmbclient and to implement the SMB VFS, complete Samba source =
code was copied over into the mc source tree.
>=20
> As you might imagine, over time, tons of issues accumulated. The most =
problematic ones were open security issues with copied Samba code, which =
were fixed upstream, but never patched back into mc. But also, since the =
code wasn=E2=80=99t getting any updates, the lack of SMB2/3 support was =
causing it to no longer work with modern Windows file servers. On top of =
that, there were innumerable encoding issues, etc.
>=20
> So, as Andrew decided to remove SMB VFS, it wasn=E2=80=99t even =
working most of the time (thus not really useful) and the code was =
impossible to fix / update.
>=20
> =E2=80=94
>=20
> We had a similar problem with our Tar VFS code, but at some point =
Andrew undertook a herculean effort to update it to the latest GNU Tar =
and keeps it in sync ever since. Actually, I=E2=80=99m still not =
super-positive as to whether this is the best decision for mc in the =
long run, but it solved a huge number of problems in the short term and =
it keeps the status quo.
>=20
> The alternative would have been to move all of the VFS code to =
libarchive (or is there any better library for that?):
>=20
>  * interface is quite stable, so little updates will be needed on the =
mc side
>  * library is rather portable and has CI coverage, so no issues with =
BSD / macOS
>  * a lot of our code can be thrown away, including extfs code
>  * archive operations will become dramatically faster
>=20
> The downside, however, is that the archive support will no longer be =
self-contained and you would need to build libarchive first to get even =
tar browsing support in mc. I think that this is not a big deal for =
distributions, but people porting mc to weird environments will get =
annoyed. However, we can provide built-in extfs scripts based on tar =
console utility as a fallback.
>=20
> We didn=E2=80=99t seriously discuss this so far, but I thought I=E2=80=99=
d mention it in the context of SMB VFS, because ultimately, it=E2=80=99s =
the same type of issue.
>=20
>>> 2.  Any advice or considerations you can share for reimplementing =
this feature
>>> in a newer version of Midnight Commander.
>=20
> I think that nothing speaks against re-accepting SMB VFS if it is =
based on libsmbclient (or is there any better client library to =
consider?), is implemented in a clean way and ideally comes with some =
tests.
>=20
> I=E2=80=99m not exactly sure what the best testing strategy could look =
like here, but probably you could mock some libsmbclient objects and =
make sure that VFS class functions return correct mc objects to the =
core.
>=20
> I guess the biggest =E2=80=9Cproblem=E2=80=9D these days is that there =
is a working CIFS client in the Linux kernel and also FUSE-based SMB =
filesystems, so motivation for having it built into mc is actually =
pretty low. Probably that=E2=80=99s why nobody tried to finish Slava=E2=80=
=99s work so far.
>=20
> One important consideration that would highly increase the chances of =
accepting the code is for you to commit to (reasonably) maintain it in =
the future after the first drop.
>=20
>>> 3.  If there were any specific design challenges or external =
dependencies
>>> (e.g., changes in libsmbclient) that influenced this decision.
>>=20
>> I think implement a smbfs on top of libsmbclient is the right (or =
even single)
>> way.
>=20
> There is some decade-old code by Slava here:
>=20
> https://github.com/MidnightCommander/mc/tree/1_smbfs
>=20
> Not sure whether it=E2=80=99s a good idea to look at it or not. I =
guess the best approach would be to take some VFS like =E2=80=9Csftpfs=E2=80=
=9D and try to understand how it works. Then copy it into =E2=80=9Csmbfs=E2=
=80=9D and try to implement something at all with the help of libsmbfs, =
using hardcoded values instead of proper dialogs, etc. In this process, =
if some problems come up, look at Slava=E2=80=99s and old stuff. And =
then have a final look after you are pretty much done.=20
>=20
> Anyways, I believe that the biggest challenge of all to win our hearts =
is simply to exhibit some good software craftsmanship and basic =
communication skills.
>=20
> The typical contributions we get, unfortunately, play out roughly as =
follows: we receive a huge dump of questionable C code in *one* commit, =
not using proper library functions, not adhering to the project style, =
badly formatted and obviously without any tests. After that the =
submitter starts putting pressure along the lines of, hey, I=E2=80=99ve =
invested so much time in my awesome contribution, and you guys are =
ghosting me instead of committing directly to master!!!11 Any attempts =
to get the submitter to bring the code in a better shape mostly fail. =
Everyone vents their frustration and anger, and the patch keeps floating =
around for the next decade or more. Fine.
>=20
> Don=E2=80=99t be like this, that=E2=80=99s your challenge ;-)
>=20
> P.S. You have already earned half of a gold star for reaching out.
>=20
> All the best,
> Yury
>=20
>=20
>=20


--Apple-Mail=_9B5B9CCD-6052-49F8-A668-20CD271558E4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"overflow-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;">Lol, wrong =
list :-/<br id=3D"lineBreakAtBeginningOfMessage"><div><br><blockquote =
type=3D"cite"><div>Begin forwarded message:</div><div><br><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px;"><span style=3D"font-family: -webkit-system-font, =
Helvetica Neue, Helvetica, sans-serif; color:rgba(127, 127, 127, =
1.0);"><b>From: </b></span><span style=3D"font-family: =
-webkit-system-font, Helvetica Neue, Helvetica, sans-serif;">"Yury V. =
Zaytsev" &lt;[email protected]&gt;<br></span></div><div style=3D"margin-top:=
 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span =
style=3D"font-family: -webkit-system-font, Helvetica Neue, Helvetica, =
sans-serif; color:rgba(127, 127, 127, 1.0);"><b>Subject: =
</b></span><span style=3D"font-family: -webkit-system-font, Helvetica =
Neue, Helvetica, sans-serif;"><b>Re: Subject: Inquiry About Samba VFS =
Feature in Midnight Commander</b><br></span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px;"><span style=3D"font-family: -webkit-system-font, =
Helvetica Neue, Helvetica, sans-serif; color:rgba(127, 127, 127, =
1.0);"><b>Date: </b></span><span style=3D"font-family: =
-webkit-system-font, Helvetica Neue, Helvetica, sans-serif;">19. January =
2025 at 11:06:35 GMT+1<br></span></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span =
style=3D"font-family: -webkit-system-font, Helvetica Neue, Helvetica, =
sans-serif; color:rgba(127, 127, 127, 1.0);"><b>To: </b></span><span =
style=3D"font-family: -webkit-system-font, Helvetica Neue, Helvetica, =
sans-serif;">Daphne Susan Saju =
&lt;daphne.saju-nc6IDEaYbZfbFSlKd4bkJ/d9D2ou9A/[email protected]&gt;<br></span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px;"><span style=3D"font-family: -webkit-system-font, =
Helvetica Neue, Helvetica, sans-serif; color:rgba(127, 127, 127, =
1.0);"><b>Cc: </b></span><span style=3D"font-family: =
-webkit-system-font, Helvetica Neue, Helvetica, sans-serif;">Andrew =
Borodin &lt;[email protected]&gt;, =
[email protected]<br></span></div><br><br>Hi Daphne,<br><br>I=E2=80=99m =
putting the mc-devel@ on CC, since I think that discussions on this =
topic do belong there and might be of interest for a wider =
audience.<br><br>I have a few comments in addition to what Andrew said, =
which will hopefully be of some help:<br><br><blockquote type=3D"cite">On =
19. Jan 2025, at 09:46, Andrew Borodin &lt;[email protected]&gt; =
wrote:<br><br><blockquote type=3D"cite">1. &nbsp;The primary reasons =
behind the decision to remove this feature=E2=80=94were =
there<br>specific technical challenges, security concerns, or =
maintainability issues?<br></blockquote><br>The primary reason is a =
bundled ancient Samba code.<br>Please see =
https://midnight-commander.org/ticket/1 and related tickets for =
details.<br></blockquote><br>Just to expand on that a little =
bit:<br><br>Early versions of Samba weren=E2=80=99t built in a modular =
way (there was no libsmbclient and to implement the SMB VFS, complete =
Samba source code was copied over into the mc source tree.<br><br>As you =
might imagine, over time, tons of issues accumulated. The most =
problematic ones were open security issues with copied Samba code, which =
were fixed upstream, but never patched back into mc. But also, since the =
code wasn=E2=80=99t getting any updates, the lack of SMB2/3 support was =
causing it to no longer work with modern Windows file servers. On top of =
that, there were innumerable encoding issues, etc.<br><br>So, as Andrew =
decided to remove SMB VFS, it wasn=E2=80=99t even working most of the =
time (thus not really useful) and the code was impossible to fix / =
update.<br><br>=E2=80=94<br><br>We had a similar problem with our Tar =
VFS code, but at some point Andrew undertook a herculean effort to =
update it to the latest GNU Tar and keeps it in sync ever since. =
Actually, I=E2=80=99m still not super-positive as to whether this is the =
best decision for mc in the long run, but it solved a huge number of =
problems in the short term and it keeps the status quo.<br><br>The =
alternative would have been to move all of the VFS code to libarchive =
(or is there any better library for that?):<br><br> &nbsp;* interface is =
quite stable, so little updates will be needed on the mc side<br> =
&nbsp;* library is rather portable and has CI coverage, so no issues =
with BSD / macOS<br> &nbsp;* a lot of our code can be thrown away, =
including extfs code<br> &nbsp;* archive operations will become =
dramatically faster<br><br>The downside, however, is that the archive =
support will no longer be self-contained and you would need to build =
libarchive first to get even tar browsing support in mc. I think that =
this is not a big deal for distributions, but people porting mc to weird =
environments will get annoyed. However, we can provide built-in extfs =
scripts based on tar console utility as a fallback.<br><br>We didn=E2=80=99=
t seriously discuss this so far, but I thought I=E2=80=99d mention it in =
the context of SMB VFS, because ultimately, it=E2=80=99s the same type =
of issue.<br><br><blockquote type=3D"cite"><blockquote type=3D"cite">2. =
&nbsp;Any advice or considerations you can share for reimplementing this =
feature<br>in a newer version of Midnight =
Commander.<br></blockquote></blockquote><br>I think that nothing speaks =
against re-accepting SMB VFS if it is based on libsmbclient (or is there =
any better client library to consider?), is implemented in a clean way =
and ideally comes with some tests.<br><br>I=E2=80=99m not exactly sure =
what the best testing strategy could look like here, but probably you =
could mock some libsmbclient objects and make sure that VFS class =
functions return correct mc objects to the core.<br><br>I guess the =
biggest =E2=80=9Cproblem=E2=80=9D these days is that there is a working =
CIFS client in the Linux kernel and also FUSE-based SMB filesystems, so =
motivation for having it built into mc is actually pretty low. Probably =
that=E2=80=99s why nobody tried to finish Slava=E2=80=99s work so =
far.<br><br>One important consideration that would highly increase the =
chances of accepting the code is for you to commit to (reasonably) =
maintain it in the future after the first drop.<br><br><blockquote =
type=3D"cite"><blockquote type=3D"cite">3. &nbsp;If there were any =
specific design challenges or external dependencies<br>(e.g., changes in =
libsmbclient) that influenced this decision.<br></blockquote><br>I think =
implement a smbfs on top of libsmbclient is the right (or even =
single)<br>way.<br></blockquote><br>There is some decade-old code by =
Slava =
here:<br><br>https://github.com/MidnightCommander/mc/tree/1_smbfs<br><br>N=
ot sure whether it=E2=80=99s a good idea to look at it or not. I guess =
the best approach would be to take some VFS like =E2=80=9Csftpfs=E2=80=9D =
and try to understand how it works. Then copy it into =E2=80=9Csmbfs=E2=80=
=9D and try to implement something at all with the help of libsmbfs, =
using hardcoded values instead of proper dialogs, etc. In this process, =
if some problems come up, look at Slava=E2=80=99s and old stuff. And =
then have a final look after you are pretty much done. <br><br>Anyways, =
I believe that the biggest challenge of all to win our hearts is simply =
to exhibit some good software craftsmanship and basic communication =
skills.<br><br>The typical contributions we get, unfortunately, play out =
roughly as follows: we receive a huge dump of questionable C code in =
*one* commit, not using proper library functions, not adhering to the =
project style, badly formatted and obviously without any tests. After =
that the submitter starts putting pressure along the lines of, hey, =
I=E2=80=99ve invested so much time in my awesome contribution, and you =
guys are ghosting me instead of committing directly to master!!!11 Any =
attempts to get the submitter to bring the code in a better shape mostly =
fail. Everyone vents their frustration and anger, and the patch keeps =
floating around for the next decade or more. Fine.<br><br>Don=E2=80=99t =
be like this, that=E2=80=99s your challenge ;-)<br><br>P.S. You have =
already earned half of a gold star for reaching out.<br><br>All the =
best,<br>Yury<br><br><br><br></div></blockquote></div><br></body></html>=

--Apple-Mail=_9B5B9CCD-6052-49F8-A668-20CD271558E4--

--===============4600988737513457203==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

-- 
mc-devel mailing list
mc-devel-+hD5IHI5XseWCegYutOAJTiNl0CLU6MPYPYVAmT7z5s@public.gmane.org
https://lists.midnight-commander.org/mailman/listinfo/mc-devel

--===============4600988737513457203==--