Removing launchSettings.json from project templates

I noticed that the new templates used in ASP.NET Core 2.1 have the launchSettings.json files present. The templates in the previous version of the framework didn't have these files.
Seems like the files contain the default settings for the app anyway, so they're not providing much value in the first place.
The main issue though is the fact that their presence will prevent overriding settings using environment variables.
For example, consider this:
docker run -p 3001:5001 -p 3000:5000 -it --rm --name dotnetwebtest -e ASPNETCORE_URLS=https://*:5001 microsoft/dotnet:2.1-sdk-alpine

# dotnet new mvc -n testapp
# cd testapp
# dotnet run
Using launch settings from /testapp/Properties/launchSettings.json...
[...]
Hosting environment: Development
Content root path: /testapp
Now listening on: https://localhost:5001
Now listening on: http://localhost:5000
Application started. Press Ctrl+C to shut down.

The app ignores the environment variable I passed because it's overridden in launchSettings.json
I suggest reverting back to previous behaviour by removing the launch settings files, to make the templates create an app that behaves as described in the docs.

Another approach is https://github.com/aspnet/Hosting/issues/1326, to be able to override all those options via command line arguments while keeping the launchSettings.json (which has its significance).
CC @davidfowl

Hmm.. I don't think that issue is relevant here, tbh. This PR tries to fix an issue with the templates that was added in 2.1, and bring them back to 2.0 behaviour

@DamianEdwards / @danroth27 / @javiercn - thoughts on this?

The default environment is Production, not Development. We want the environment to be Development when doing dotnet run.
We could remove setting ASPNETCORE_URLS from launchSettings.json. We only had it there as a convenience so that folks can discover a way to set it. But maybe it causes more harm than good.

The behavior was changed intentionally, namely to get the environment set by default in CLI scenarios, and as part of the new HTTPS by default work. But as Dan says, we can likely remove the URLS var without issue.

dotnet run is a development command hence it runs with development settings. This makes the experience of running the app from command line with dotnet run and running the app from visual studio similar and its a deliberate choice.
For docker we've moved to a multi-step build process, using an image to build the app and another image to run the built app, inside docker you should always run your app with dotnet <> -- <>
@danroth27 I would be ok with tooling respecting existing environment variables over those defined in/by launchSettings.json but that would be a tooling change.

@danroth27 / @DamianEdwards / @javiercn - can you provide more clarity on exactly what change(s) you propose would work for us?

We can't revert anything on this file, only how tooling interprets it and what it gives precedence to.
ASPNETCORE_URLS will go away in preview2 in favor of applicationUrl, but that won't change anything as the meaning tooling gives applicationUrl is to setup ASPNETCORE_URLS and that would override anything defined in your environment.
The only thing we could consider doing is to change tooling to prefer/preserve things already in your environment.
You should not run your app inside a container with dotnet run but with dotnet <<path-to-dll>>. dotnet run is intended for development and to use launchSettings.json

@danroth27 @DamianEdwards @javiercn I see, this makes perfect sense.
Removing the environment variable won't break the https by default work, since it has the default value anyway. Also you can see which urls the app runs on in the output of dotnet run.
I can certainly see the point of making this feature more discoverable though. So how about this option then? Json doesn't support commenting options, but nothing stops us from naming the property "//ASPNETCORE_URLS" in json. It's discoverable, and easy to see as a commented field. Does that look better?

Having thought more on this and reading the comments above, I realised that this wasn't really a necessary change in the first place. Even in the edge cases when someone would want to run the app using dotnet run vs running a deployed version (unit testing? during development using containers?) they could just as easily configure their launchSettings.json and commit that to their repo, so this change is indeed unnecessary.
Now I feel silly after wasting everyone's time on this 😅

@artiomchi Don't worry about it. We are here to help :)


Update Python comment style

The PEP8(Style Guide for Python Code) said:

An inline comment is a comment on the same line as a statement.
Inline comments should be separated by at least two spaces from the statement.
They should start with a # and a single space.

Fork notice: With the upstream project sitting stale after nearly 8 months since the last activity, 71 outstanding pull requests, no comments from the original developer, and dozens of developers duplicating efforts while scratching their own itches, I've decided to step in and run a fork for a while. Hopefully the original developer will eventually consider picking this plugin up again or adding more maintainers so that the user base doesn't end up fragmented, but for now I would invite anyone interested in the latest updates to consider installing from and contributing pull requests to my fork.
About this PR: I would have merged this PR, but as it stands there are several reasons to think this isn't the right solution. There is already an option for adding spaces after delimiters and it seems better to use that then fight over the best default (personally I think most languages look better with).

Change of plans. Thanks to scrooloose who has added me as a maintainer to this repo, I'll be going through and taking care of business here instead of in a fork.
Per the comments above, I have some reservations about this. I understand why matching the languages own style guide would be a good thing, but the space issue has a config option already so I don't think adding it as part of the delimiter is such a great idea especially when technically it works without as well.
Perhaps if there was a way to trigger the space handling setting by default on a per language basis? How would that sit with folks?

As of #183 having been merged (and re-fixed in #239 after I broke it) this is the default behavior so I'm going to close this PR as a duplicate. Please also see #202 for discussion about whether this is actually the right solution or not.


UploadFile returns Success but file is only partially uploaded

FTP Server OS: Synology
FTP Server Type: Synology 7.1.x
Client Computer OS: Windows
FluentFTP Version: 34.0.2 ~ 48.0.3
Framework: .NET core 2.2 ~ 8
Maybe #1358 has a similar issue like mine but just doesn't know it.
So i basically have always uploaded to a very remote server with bad connection circumstances.
A couple of weeks ago i'm using wifi (yes i know) to upload files to the ftp server and am suffering even more upload issues.
And today i finally noticed the UploadFile method returning success while the upload wasn't fully uploaded yet.
But if i run GetFileSize it's able to correctly return the correct size from the remote file.
So as a work around i have added a extra check after i'm done uploading a file to check the size,
and to resume the upload until it's completed.
Logs :

<paste VERBOSE logs here>

Code:
// here i create a AsyncFtpClient, no weird configs\overrides fyi

for (var i = 1; i < 99; i++)
{
    try
    {
        if (!ftpclient.IsConnected || !ftpclient.IsAuthenticated)
        {
            await ftpclient.Connect(uploadProfile);
        }

        var result = await ftpclient.UploadFile(
            archivePath,
            $"/{DateTime.Now:yyyy-MM-dd}/" + archiveFileName,
            FtpRemoteExists.Resume,
            true,
            FtpVerify.Retry,
            new Progress<FtpProgress>(p => progress.Tick((int)p.Progress, p.ETA, $"{p.TransferSpeedToString()} uploading to ftp... attempt: {i}")));

        //// i have some code here now that double checks the filesize and prevents it from breaking the loop.

        if (result == FtpStatus.Success)
        {
            break;
        }
    }
    catch (Exception ex)
    {
       //// some logging code etc, also just restarts the loop
    }

    if (ftpclient.IsConnected)
    {
        await ftpclient.Disconnect();
    }
}

And today i finally noticed the UploadFile method returning success while the upload wasn't fully uploaded yet.
But if i run GetFileSize it's able to correctly return the correct size from the remote file.
So as a work around i have added a extra check after i'm done uploading a file to check the size,

Success, but not fully uploaded? Need to see a verbose log of that happening. In the log, I can see the file size, the number of bytes uploaded and the completion message.

But it's a real issue that I've been running against for a couple of days even with files that are a couple megabytes

Any logger is fine, just generate the logs and paste it here.

this is attempt 27....
06:50:37.022	Verbose	>         Connect(False)
06:50:37.023	Verbose	Status:   FluentFTP <IP_ADDRESS>(.NET 6.0)
06:50:37.024	Info	Status:   Connecting to IP #1= ***:21
06:50:37.025	Verbose	Status:   Waiting for a response
06:50:37.255	Info	Response: 220 oneNAS FTP server ready. [19.883s]
06:50:37.256	Info	Command:  AUTH TLS
06:50:37.257	Verbose	Status:   Waiting for response to: AUTH TLS
06:50:37.320	Info	Response: 234 AUTH TLS command successful. [63ms]
06:50:37.320	Warn	Warning:  SSL Buffering disabled because of .NET 5.0 and later
06:50:37.466	Info	Status:   FTPS authentication successful, lib = .NET SslStream, cipher suite = Tls13 (Aes256, TLS_AES_256_GCM_SHA384, None, 0) [145ms]
06:50:37.466	Info	Command:  USER ***
06:50:37.466	Verbose	Status:   Waiting for response to: USER ***
06:50:37.541	Info	Response: 331 Password required for ***. [74ms]
06:50:37.541	Info	Command:  PASS ***
06:50:37.542	Verbose	Status:   Waiting for response to: PASS ***
06:50:37.629	Info	Response: 230 User *** logged in. [87ms]
06:50:37.630	Info	Command:  PBSZ 0
06:50:37.630	Verbose	Status:   Waiting for response to: PBSZ 0
06:50:37.700	Info	Response: 200 PBSZ command successful (PBSZ=0). [70ms]
06:50:37.701	Info	Command:  PROT P
06:50:37.701	Verbose	Status:   Waiting for response to: PROT P
06:50:37.766	Info	Response: 200 Protection level set to Private. [65ms]
06:50:37.767	Info	Command:  FEAT
06:50:37.767	Verbose	Status:   Waiting for response to: FEAT
06:50:37.832	Verbose	Response: 211- Extensions supported:
Response: AUTH TLS
Response: PBSZ
Response: PROT
Response: CCC
Response: SIZE
Response: MDTM
Response: REST STREAM
Response: MFMT
Response: TVFS
Response: MLST modify*;type*;unique*;size*;UNIX.mode*;UNIX.owner*;UNIX.group*;
Response: MLSD modify*;type*;unique*;size*;UNIX.mode*;UNIX.owner*;UNIX.group*;
Response: UTF8
06:50:37.833	Info	Response: 211 End. [65ms]
06:50:37.834	Info	Status:   Text encoding: System.Text.UTF8Encoding+UTF8EncodingSealed
06:50:37.834	Info	Command:  OPTS UTF8 ON
06:50:37.834	Verbose	Status:   Waiting for response to: OPTS UTF8 ON
06:50:37.914	Info	Response: 200 OK, UTF-8 enabled [80ms]
06:50:37.915	Info	Command:  SYST
06:50:37.915	Verbose	Status:   Waiting for response to: SYST
06:50:37.988	Info	Response: 215 UNIX Type: L8 [73ms]
06:50:37.989	Verbose	Status:   Listing parser set to: Machine
06:50:37.989	Info	Command:  PWD
06:50:37.989	Verbose	Status:   Waiting for response to: PWD
06:50:38.061	Info	Response: 257 "/" is current directory. [72ms]
06:50:38.062	Verbose	>         UploadFile("C:\Temp\uploadme.7z", "/backup/2023-11-17/uploadme.7z", Resume, True, Retry)
06:50:38.062	Verbose	>         FileExists("/backup/2023-11-17/uploadme.7z")
06:50:38.063	Verbose	>         GetNameListing("/backup/2023-11-17")
06:50:38.063	Info	Command:  TYPE I
06:50:38.065	Verbose	Status:   Waiting for response to: TYPE I
06:50:38.140	Info	Response: 200 Type set to I. [74ms]
06:50:38.141	Verbose	>         OpenDataStreamAsync("NLST /backup/2023-11-17", 0)
06:50:38.141	Verbose	>         OpenPassiveDataStreamAsync(EPSV, "NLST /backup/2023-11-17", 0)
06:50:38.141	Info	Command:  EPSV
06:50:38.141	Verbose	Status:   Waiting for response to: EPSV
06:50:38.207	Info	Response: 229 Entering Extended Passive Mode (|||55537|) [66ms]
06:50:38.208	Info	Status:   Connecting to IP #1= ***:55537
06:50:38.209	Info	Command:  NLST /backup/2023-11-17
06:50:38.210	Verbose	Status:   Waiting for response to: NLST /backup/2023-11-17
06:50:38.373	Info	Response: 150 Opening BINARY mode SSL data connection for 'file list'. [163ms]
06:50:38.373	Warn	Warning:  SSL Buffering disabled because of .NET 5.0 and later
06:50:38.521	Info	Status:   FTPS authentication successful, lib = .NET SslStream, cipher suite = Tls13 (Aes256, TLS_AES_256_GCM_SHA384, None, 0) [147ms]
06:50:38.521	Verbose	+---------------------------------------+
06:50:38.606	Verbose	Listing:  /backup/2023-11-17/a.7z
06:50:38.606	Verbose	Listing:  /backup/2023-11-17/b.7z
06:50:38.606	Verbose	Listing:  /backup/2023-11-17/c.7z
06:50:38.607	Verbose	Listing:  /backup/2023-11-17/d.7z
06:50:38.607	Verbose	Listing:  /backup/2023-11-17/uploadme.7z
06:50:38.607	Verbose	Status:   Closing/Disposing FtpSocketStream(data connection)
06:50:38.608	Verbose	>         CloseDataStream()
06:50:38.608	Verbose	Status:   Waiting for response to: NLST /backup/2023-11-17
06:50:38.609	Info	Response: 226 Transfer complete. [399ms]
06:50:38.609	Verbose	+---------------------------------------+
06:50:38.609	Verbose	Status:   Closing/Disposing FtpSocketStream(data connection)
06:50:38.609	Verbose	>         GetFileSize("/backup/2023-11-17/uploadme.7z", 0)
06:50:38.610	Info	Command:  SIZE /backup/2023-11-17/uploadme.7z
06:50:38.610	Verbose	Status:   Waiting for response to: SIZE /backup/2023-11-17/uploadme.7z
06:50:38.698	Info	Response:<PHONE_NUMBER>5 [88ms]
06:50:38.699	Verbose	>         OpenAppend("/backup/2023-11-17/uploadme.7z", Binary)
06:50:38.699	Verbose	>         OpenDataStreamAsync("APPE /backup/2023-11-17/uploadme.7z", 0)
06:50:38.699	Verbose	>         OpenPassiveDataStreamAsync(EPSV, "APPE /backup/2023-11-17/uploadme.7z", 0)
06:50:38.699	Info	Command:  EPSV
06:50:38.700	Verbose	Status:   Waiting for response to: EPSV
06:50:38.767	Info	Response: 229 Entering Extended Passive Mode (|||55538|) [66ms]
06:50:38.767	Info	Status:   Connecting to IP #1= ***:55538
06:50:38.769	Info	Command:  APPE /backup/2023-11-17/uploadme.7z
06:50:38.769	Verbose	Status:   Waiting for response to: APPE /backup/2023-11-17/uploadme.7z
06:50:53.777	Verbose	Status:   Closing/Disposing FtpSocketStream(control connection)

Seems like when reusing the same AsyncFtpClient instance.
Some state gets saved and used in some way.
I had to modify my code so it creates a new AsyncFtpClient instance for every attempt and that works better.
But it still fails to completely upload the whole file to the ftp server.
(sorry for the late reply)

Ok, I can see a number of things going wrong here.

Warning:  Reconnect needed due to max SslSessionLength reached on control connection (SslSessionLength: 753)
I need to investigate this. First of all, such a reconnect should better not be initiated during a connect (duh!) That's a problem (#1) of ours.
So from attempt 28 and onwards, you need to disregard - it's a different problem.
Let's concentrate on the actual first problem:

06:50:38.769	Info	Command:  APPE /backup/2023-11-17/uploadme.7z
06:50:38.769	Verbose	Status:   Waiting for response to: APPE /backup/2023-11-17/uploadme.7z
06:50:53.777	Verbose	Status:   Closing/Disposing FtpSocketStream(control connection)

Sadly, I can't see the lines following that. I suppose it is QUIT and disconnect.
Ok, what we've got is no response on the APPE, but instead a premature close on the control connection. Any response, especially an error message from the server, has not arrived. A possible scenario is for example (just an example, ok?) that the server runs out of space, sends an error message an immediately closes all its connections, we somehow don't even get the error message.
There are other possibilites, but this is what we would need to concentrate on.

Some state gets saved and used in some way.

Yes, it looks like the SslSessionLength counter should be reset whenever a disconnect takes place, problem #2 of ours. Your approach to

creates a new AsyncFtpClient instance for every attempt

is a valid workaround for this problem.
Here is my todo list on this issue:
I will try to fix these two reconnect problems.
Finding out what is going wrong on your APPE, why is there no error message, you could possibly help on that: Can you do a wireshark trace of this?

I'm the only one using the ftp server (There are a couple other users but those are just doing reads with http).
It still has more then enough storage space and room for having ftp connections.
BUT it's on a high latency and flaky connection (over the internet), and me using wifi on top of that isn't helping ofcourse.
Uhhmmmm me doing a wireshark trace is not going to be easy... I'm transfering multiple gigabytes worth of files...

Fair enough. Don't worry. Your approach to retry and APPE is ok, let's get that working then. Can you use a test branch of mine, I've fixed the two problems (I hope)?

Just direct me to a custom feed or branch and i'll try having a run with it

This one:
https://github.com/FanDjango/FluentFTP/tree/test

all of the initial connect attempts look like this now
06:38:49.952	Verbose	>         Connect(False)
06:38:49.953	Verbose	Status:   FluentFTP <IP_ADDRESS>(.NET 6.0)
06:38:49.954	Info	Status:   Connecting to IP #1= ***:21
06:38:49.956	Verbose	Status:   Waiting for a response
06:38:50.145	Info	Response: 220 oneNAS FTP server ready. [738844.277d]
06:38:50.147	Info	Command:  AUTH TLS
06:38:50.147	Verbose	Status:   Waiting for response to: AUTH TLS
06:38:50.234	Info	Response: 234 AUTH TLS command successful. [86ms]
06:38:50.235	Warn	Warning:  SSL Buffering disabled because of .NET 5.0 and later
06:38:50.434	Info	Status:   FTPS authentication successful, lib = .NET SslStream, cipher suite = Tls13 (Aes256, TLS_AES_256_GCM_SHA384, None, 0) [199ms]
06:38:50.435	Info	Command:  USER ***
06:38:50.435	Verbose	Status:   Waiting for response to: USER ***
06:38:50.538	Info	Response: 331 Password required for ***. [103ms]
06:38:50.539	Info	Command:  PASS ***
06:38:50.539	Verbose	Status:   Waiting for response to: PASS ***
06:38:50.824	Info	Response: 230 User *** logged in. [285ms]
06:38:50.825	Info	Command:  PBSZ 0
06:38:50.825	Verbose	Status:   Waiting for response to: PBSZ 0
06:38:50.890	Info	Response: 200 PBSZ command successful (PBSZ=0). [64ms]
06:38:50.890	Info	Command:  PROT P
06:38:50.890	Verbose	Status:   Waiting for response to: PROT P
06:38:50.980	Info	Response: 200 Protection level set to Private. [89ms]
06:38:50.980	Info	Command:  FEAT
06:38:50.980	Verbose	Status:   Waiting for response to: FEAT
06:38:51.082	Verbose	Response: 211- Extensions supported:
Response: AUTH TLS
Response: PBSZ
Response: PROT
Response: CCC
Response: SIZE
Response: MDTM
Response: REST STREAM
Response: MFMT
Response: TVFS
Response: MLST modify*;type*;unique*;size*;UNIX.mode*;UNIX.owner*;UNIX.group*;
Response: MLSD modify*;type*;unique*;size*;UNIX.mode*;UNIX.owner*;UNIX.group*;
Response: UTF8
06:38:51.083	Info	Response: 211 End. [102ms]
06:38:51.083	Info	Status:   Text encoding: System.Text.UTF8Encoding+UTF8EncodingSealed
06:38:51.083	Info	Command:  OPTS UTF8 ON
06:38:51.084	Verbose	Status:   Waiting for response to: OPTS UTF8 ON
06:38:51.176	Info	Response: 200 OK, UTF-8 enabled [92ms]
06:38:51.176	Info	Command:  SYST
06:38:51.176	Verbose	Status:   Waiting for response to: SYST
06:38:51.241	Info	Response: 215 UNIX Type: L8 [65ms]
06:38:51.242	Verbose	Status:   Listing parser set to: Machine
06:38:51.242	Info	Command:  PWD
06:38:51.243	Verbose	Status:   Waiting for response to: PWD
06:38:51.308	Info	Response: 257 "/" is current directory. [65ms]
06:38:51.310	Verbose	>         UploadFile("C:\temp\uploadme.7z", "/backup/2023-11-21/uploadme.7z", Resume, True, Retry)
06:38:51.310	Verbose	>         FileExists("/backup/2023-11-21/uploadme.7z")
06:38:51.311	Verbose	>         GetNameListing("/backup/2023-11-21")
06:38:51.311	Info	Command:  TYPE I
06:38:51.311	Verbose	Status:   Waiting for response to: TYPE I
06:38:51.380	Info	Response: 200 Type set to I. [68ms]
06:38:51.380	Verbose	>         OpenDataStreamAsync("NLST /backup/2023-11-21", 0)
06:38:51.381	Verbose	>         OpenPassiveDataStreamAsync(EPSV, "NLST /backup/2023-11-21", 0)
06:38:51.381	Info	Command:  EPSV
06:38:51.381	Verbose	Status:   Waiting for response to: EPSV
06:38:51.448	Info	Response: 229 Entering Extended Passive Mode (|||55536|) [66ms]
06:38:51.449	Info	Status:   Connecting to IP #1= ***:55536
06:38:51.450	Info	Command:  NLST /backup/2023-11-21
06:38:51.450	Verbose	Status:   Waiting for response to: NLST /backup/2023-11-21
06:38:51.683	Info	Response: 150 Opening BINARY mode SSL data connection for 'file list'. [232ms]
06:38:51.683	Warn	Warning:  SSL Buffering disabled because of .NET 5.0 and later
06:38:51.822	Info	Status:   FTPS authentication successful, lib = .NET SslStream, cipher suite = Tls13 (Aes256, TLS_AES_256_GCM_SHA384, None, 0) [138ms]
06:38:51.822	Verbose	+---------------------------------------+

sorry no thats just the part that is the same on all attempts....
i forgot to attach all the attempts (and the exceptions that i captured to the wrong file....)
so attempt 1 is like this (no exceptions) but it says\thinks it uploaded everything, but the filesize it gets afterwards isn't complete
06:49:41.600	Verbose	+---------------------------------------+
06:49:41.667	Verbose	Status:   Closing/Disposing FtpSocketStream(data connection)
06:49:41.669	Verbose	>         CloseDataStream()
06:49:41.669	Verbose	Status:   Waiting for response to: NLST /backup/2023-11-22
06:49:41.670	Info	Response: 226 Transfer complete. [412ms]
06:49:41.670	Verbose	+---------------------------------------+
06:49:41.670	Verbose	Status:   Closing/Disposing FtpSocketStream(data connection)
06:49:41.671	Verbose	>         DirectoryExists("/backup/2023-11-22")
06:49:41.671	Info	Command:  CWD /backup/2023-11-22
06:49:41.671	Verbose	Status:   Waiting for response to: CWD /backup/2023-11-22
06:49:41.758	Info	Response: 250 CWD command successful. [86ms]
06:49:41.758	Info	Command:  CWD /
06:49:41.758	Verbose	Status:   Waiting for response to: CWD /
06:49:41.823	Info	Response: 250 CWD command successful. [64ms]
06:49:41.824	Verbose	>         OpenWrite("/backup/2023-11-22/uploadme.7z", Binary)
06:49:41.824	Verbose	>         OpenDataStreamAsync("STOR /backup/2023-11-22/uploadme.7z", 0)
06:49:41.824	Verbose	>         OpenPassiveDataStreamAsync(EPSV, "STOR /backup/2023-11-22/uploadme.7z", 0)
06:49:41.824	Info	Command:  EPSV
06:49:41.825	Verbose	Status:   Waiting for response to: EPSV
06:49:41.892	Info	Response: 229 Entering Extended Passive Mode (|||55537|) [66ms]
06:49:41.892	Info	Status:   Connecting to IP #1= ***:55537
06:49:41.893	Info	Command:  STOR /backup/2023-11-22/uploadme.7z
06:49:41.893	Verbose	Status:   Waiting for response to: STOR /backup/2023-11-22/uploadme.7z
06:49:42.054	Info	Response: 150 Opening BINARY mode SSL data connection for '/backup/2023-11-22/uploadme.7z'. [160ms]
06:49:42.055	Warn	Warning:  SSL Buffering disabled because of .NET 5.0 and later
06:49:42.197	Info	Status:   FTPS authentication successful, lib = .NET SslStream, cipher suite = Tls13 (Aes256, TLS_AES_256_GCM_SHA384, None, 0) [142ms]
06:49:42.261	Verbose	Status:   Uploaded 2683163 bytes
06:49:42.262	Verbose	Status:   Closing/Disposing FtpSocketStream(data connection)
06:49:42.263	Verbose	Status:   Waiting for response to: STOR /backup/2023-11-22/uploadme.7z
06:49:42.371	Info	Response: 226 Transfer complete. [477ms]
06:49:42.372	Info	Status:   File Verification: PASS
06:49:42.372	Verbose	>         GetFileSize("/backup/2023-11-22/uploadme.7z", -1)
06:49:42.373	Info	Command:  SIZE /backup/2023-11-22/uploadme.7z
06:49:42.373	Verbose	Status:   Waiting for response to: SIZE /backup/2023-11-22/uploadme.7z
06:49:42.448	Info	Response: 213 163742 [75ms]
06:49:42.449	Info	Command:  QUIT
06:49:42.449	Verbose	Status:   Waiting for response to: QUIT
06:49:42.517	Info	Response: 221 Goodbye. You uploaded 159.90 KB and downloaded 0 bytes. [67ms]
06:49:42.518	Verbose	Status:   Closing/Disposing FtpSocketStream(control connection)

and attempt 2~5 look like this with a socket exception happening
06:50:01.435	Verbose	+---------------------------------------+
06:50:01.506	Verbose	Listing:  /backup/2023-11-22/uploadme.7z
06:50:01.507	Verbose	Status:   Closing/Disposing FtpSocketStream(data connection)
06:50:01.507	Verbose	>         CloseDataStream()
06:50:01.508	Verbose	Status:   Waiting for response to: NLST /backup/2023-11-22
06:50:01.508	Info	Response: 226 Transfer complete. [379ms]
06:50:01.508	Verbose	+---------------------------------------+
06:50:01.508	Verbose	Status:   Closing/Disposing FtpSocketStream(data connection)
06:50:01.508	Verbose	>         GetFileSize("/backup/2023-11-22/uploadme.7z", 0)
06:50:01.508	Info	Command:  SIZE /backup/2023-11-22/uploadme.7z
06:50:01.508	Verbose	Status:   Waiting for response to: SIZE /backup/2023-11-22/uploadme.7z
06:50:01.574	Info	Response: 213 163742 [65ms]
06:50:01.575	Verbose	>         OpenAppend("/backup/2023-11-22/uploadme.7z", Binary)
06:50:01.575	Verbose	>         OpenDataStreamAsync("APPE /backup/2023-11-22/uploadme.7z", 0)
06:50:01.575	Verbose	>         OpenPassiveDataStreamAsync(EPSV, "APPE /backup/2023-11-22/uploadme.7z", 0)
06:50:01.575	Info	Command:  EPSV
06:50:01.576	Verbose	Status:   Waiting for response to: EPSV
06:50:01.645	Info	Response: 229 Entering Extended Passive Mode (|||55538|) [69ms]
06:50:01.645	Info	Status:   Connecting to IP #1= ***:55538
06:50:01.647	Info	Command:  APPE /backup/2023-11-22/uploadme.7z
06:50:01.647	Verbose	Status:   Waiting for response to: APPE /backup/2023-11-22/uploadme.7z
06:50:16.657	Verbose	Status:   Closing/Disposing FtpSocketStream(control connection)

06:50:16.662	EXCEPTION!
Exception: Error while uploading the file to the server. See InnerException for more info.
   at FluentFTP.AsyncFtpClient.UploadFileInternalAsync(Stream fileData, String localPath, String remotePath, Boolean createRemoteDir, FtpRemoteExists existsMode, Boolean fileExists, Boolean fileExistsKnown, IProgress`1 progress, CancellationToken token, FtpProgress metaProgress) in C:\src\Tools\FluentFTP-test\FluentFTP\Client\AsyncClient\UploadFileInternal.cs:line 324
   at FluentFTP.AsyncFtpClient.UploadFileFromFile(String localPath, String remotePath, Boolean createRemoteDir, FtpRemoteExists existsMode, Boolean fileExists, Boolean fileExistsKnown, FtpVerify verifyOptions, CancellationToken token, IProgress`1 progress, FtpProgress metaProgress) in C:\src\Tools\FluentFTP-test\FluentFTP\Client\AsyncClient\UploadFile.cs:line 76
   at FluentFTP.AsyncFtpClient.UploadFile(String localPath, String remotePath, FtpRemoteExists existsMode, Boolean createRemoteDir, FtpVerify verifyOptions, IProgress`1 progress, CancellationToken token) in C:\src\Tools\FluentFTP-test\FluentFTP\Client\AsyncClient\UploadFile.cs:line 44
   at uploader.Program.BackupCompressUploadJob(BackendTenantInfo tenant, Boolean reporting) in C:\src\Tools\uploader\Program.cs:line 1837
Exception: Timed out trying to read data from the socket stream!
   at FluentFTP.FtpSocketStream.ReadAsync(Byte[] buffer, Int32 offset, Int32 count, CancellationToken token) in C:\src\Tools\FluentFTP-test\FluentFTP\Streams\FtpSocketStream.cs:line 588
   at FluentFTP.FtpSocketStream.ReadLineAsync(Encoding encoding, CancellationToken token) in C:\src\Tools\FluentFTP-test\FluentFTP\Streams\FtpSocketStream.cs:line 675
   at FluentFTP.AsyncFtpClient.GetReplyAsyncInternal(CancellationToken token, String command, Boolean exhaustNoop, Int32 timeOut) in C:\src\Tools\FluentFTP-test\FluentFTP\Client\AsyncClient\GetReply.cs:line 132
   at FluentFTP.AsyncFtpClient.GetReplyAsyncInternal(CancellationToken token, String command) in C:\src\Tools\FluentFTP-test\FluentFTP\Client\AsyncClient\GetReply.cs:line 30
   at FluentFTP.AsyncFtpClient.Execute(String command, CancellationToken token) in C:\src\Tools\FluentFTP-test\FluentFTP\Client\AsyncClient\Execute.cs:line 91
   at FluentFTP.AsyncFtpClient.OpenPassiveDataStreamAsync(FtpDataConnectionType type, String command, Int64 restart, CancellationToken token) in C:\src\Tools\FluentFTP-test\FluentFTP\Client\AsyncClient\OpenPassiveDataStream.cs:line 132
   at FluentFTP.AsyncFtpClient.OpenDataStreamAsync(String command, Int64 restart, CancellationToken token) in C:\src\Tools\FluentFTP-test\FluentFTP\Client\AsyncClient\OpenDataStream.cs:line 57
   at FluentFTP.AsyncFtpClient.OpenAppendInternal(String path, FtpDataType type, Int64 fileLen, Boolean ignoreStaleData, CancellationToken token) in C:\src\Tools\FluentFTP-test\FluentFTP\Client\AsyncClient\OpenAppend.cs:line 72
   at FluentFTP.AsyncFtpClient.UploadFileInternalAsync(Stream fileData, String localPath, String remotePath, Boolean createRemoteDir, FtpRemoteExists existsMode, Boolean fileExists, Boolean fileExistsKnown, IProgress`1 progress, CancellationToken token, FtpProgress metaProgress) in C:\src\Tools\FluentFTP-test\FluentFTP\Client\AsyncClient\UploadFileInternal.cs:line 155

when my connection finally starts working again i get this (again not uploading everything)
06:51:09.986	Verbose	+---------------------------------------+
06:51:10.046	Verbose	Listing:  /backup/2023-11-22/uploadme.7z
06:51:10.047	Verbose	Status:   Closing/Disposing FtpSocketStream(data connection)
06:51:10.048	Verbose	>         CloseDataStream()
06:51:10.048	Verbose	Status:   Waiting for response to: NLST /backup/2023-11-22
06:51:10.048	Info	Response: 226 Transfer complete. [380ms]
06:51:10.048	Verbose	+---------------------------------------+
06:51:10.049	Verbose	Status:   Closing/Disposing FtpSocketStream(data connection)
06:51:10.049	Verbose	>         GetFileSize("/backup/2023-11-22/uploadme.7z", 0)
06:51:10.049	Info	Command:  SIZE /backup/2023-11-22/uploadme.7z
06:51:10.049	Verbose	Status:   Waiting for response to: SIZE /backup/2023-11-22/uploadme.7z
06:51:10.123	Info	Response: 213 163742 [73ms]
06:51:10.123	Verbose	>         OpenAppend("/backup/2023-11-22/uploadme.7z", Binary)
06:51:10.124	Verbose	>         OpenDataStreamAsync("APPE /backup/2023-11-22/uploadme.7z", 0)
06:51:10.124	Verbose	>         OpenPassiveDataStreamAsync(EPSV, "APPE /backup/2023-11-22/uploadme.7z", 0)
06:51:10.124	Info	Command:  EPSV
06:51:10.124	Verbose	Status:   Waiting for response to: EPSV
06:51:10.193	Info	Response: 229 Entering Extended Passive Mode (|||55537|) [68ms]
06:51:10.193	Info	Status:   Connecting to IP #1= ***:55537
06:51:10.194	Info	Command:  APPE /backup/2023-11-22/uploadme.7z
06:51:10.194	Verbose	Status:   Waiting for response to: APPE /backup/2023-11-22/uploadme.7z
06:51:10.361	Info	Response: 150 Opening BINARY mode SSL data connection for '/backup/2023-11-22/uploadme.7z'. [166ms]
06:51:10.361	Warn	Warning:  SSL Buffering disabled because of .NET 5.0 and later
06:51:10.501	Info	Status:   FTPS authentication successful, lib = .NET SslStream, cipher suite = Tls13 (Aes256, TLS_AES_256_GCM_SHA384, None, 0) [140ms]
06:51:10.570	Verbose	Status:   Uploaded 2683163 bytes
06:51:10.571	Verbose	Status:   Closing/Disposing FtpSocketStream(data connection)
06:51:10.571	Verbose	Status:   Waiting for response to: APPE /backup/2023-11-22/uploadme.7z
06:51:10.674	Info	Response: 226 Transfer complete. [479ms]
06:51:10.674	Info	Status:   File Verification: PASS
06:51:10.674	Verbose	>         GetFileSize("/backup/2023-11-22/uploadme.7z", -1)
06:51:10.675	Info	Command:  SIZE /backup/2023-11-22/uploadme.7z
06:51:10.675	Verbose	Status:   Waiting for response to: SIZE /backup/2023-11-22/uploadme.7z
06:51:10.750	Info	Response: 213 327484 [75ms]
06:51:10.750	Info	Command:  QUIT
06:51:10.750	Verbose	Status:   Waiting for response to: QUIT
06:51:10.822	Info	Response: 221 Goodbye. You uploaded 159.90 KB and downloaded 0 bytes. [71ms]
06:51:10.822	Verbose	Status:   Closing/Disposing FtpSocketStream(control connection)

It kind of looks like each attempt (when the network works) will upload a block of about 159.90 KB.
Attempt 1: using STOR command to upload, size after upload is 163742
...
... Network problems, no upload works at all
...
Attempt 6: using APPE command to append, size after APPE is 327484 (which is again 163742).
I assume that further such attempts will increase the site again and again by 163742. You could confirm that perhaps?
I have some observations/questions:
The attempts to resume (--> APPE) seem to be repeatedly starting at file offset 0. So the resume logic needs to be debugged, independantly of the actual issue we are dealing with here. Possible problem, that contributes to your issue here.
Now if for example that data that you are transferring is causing an intermediate firewall or suchlike to terminate the transfer prematurely (some firewalls examine data and disconnect when they are angry), the fact that APPE (wrongly, possible bug) starting again and again from offset 0 would cause the same number of bytes being transferred each time, as the offending data is again and again at the same place.
So compare this sequence here that you documented (/backup/2023-11-22/uploadme.7z) and check the same for some other file - how does that behave? Does different data change the 163742 to some other value? And they repeat in the same fashion? Or is it still 163742?

And are you saying

FluentFTP Version: 34.0.2 ~ 48.0.3

it worked for FluentFTP Version: 34.0.2 and fails for FluentFTP Version: 48.0.3?

Just for your information: I have found and fixed an issue which causes some problems and I would like you to redo the "Attempt 1....Attempt 6,7" for me (as you did above) and to post the new log in here. I need to see at least on complete connect-FEAT-etc. also. Please use the current master in here as I have commited and merged the fixes already.

Maybe https://github.com/robinrodricks/FluentFTP/issues/1358 has a similar issue like mine but just doesn't know it.

You were right, the problems you are seeing are related to this. But it isn't the total solution - we still now need to debug why the APPE command is not working right and why the server is behaving in such a strange way.

And are you saying

FluentFTP Version: 34.0.2 ~ 48.0.3

it worked for FluentFTP Version: 34.0.2 and fails for FluentFTP Version: 48.0.3?

more like i have had that retry loop in place since then, but not sure that was because of the retry failures or it not fully uploading propperly

if you see requesting file size and got 114541 those are my own logs where my extra check code is running to verify if the upload is really completed
1st attempt:
07:59:44.207	Verbose	>         Connect(False)
07:59:44.207	Verbose	Status:   FluentFTP <IP_ADDRESS>(.NET 6.0)
07:59:44.208	Info	Status:   Connecting to IP #1= ***:21
07:59:44.209	Verbose	Status:   Waiting for a response
07:59:44.404	Info	Response: 220 oneNAS FTP server ready. [738850.333d]
07:59:44.404	Info	Command:  AUTH TLS
07:59:44.405	Verbose	Status:   Waiting for response to: AUTH TLS
07:59:44.472	Info	Response: 234 AUTH TLS command successful. [67ms]
07:59:44.475	Warn	Warning:  SSL Buffering disabled because of .NET 5.0 and later
07:59:44.640	Info	Status:   FTPS authentication successful, lib = .NET SslStream, cipher suite = Tls13 (Aes256, TLS_AES_256_GCM_SHA384, None, 0) [165ms]
07:59:44.641	Info	Command:  USER ***
07:59:44.641	Verbose	Status:   Waiting for response to: USER ***
07:59:44.712	Info	Response: 331 Password required for ***. [71ms]
07:59:44.713	Info	Command:  PASS ***
07:59:44.713	Verbose	Status:   Waiting for response to: PASS ***
07:59:44.802	Info	Response: 230 User *** logged in. [88ms]
07:59:44.803	Info	Command:  PBSZ 0
07:59:44.803	Verbose	Status:   Waiting for response to: PBSZ 0
07:59:44.870	Info	Response: 200 PBSZ command successful (PBSZ=0). [67ms]
07:59:44.871	Info	Command:  PROT P
07:59:44.872	Verbose	Status:   Waiting for response to: PROT P
07:59:44.941	Info	Response: 200 Protection level set to Private. [69ms]
07:59:44.942	Info	Command:  FEAT
07:59:44.943	Verbose	Status:   Waiting for response to: FEAT
07:59:45.019	Verbose	Response: 211- Extensions supported:
Response: AUTH TLS
Response: PBSZ
Response: PROT
Response: CCC
Response: SIZE
Response: MDTM
Response: REST STREAM
Response: MFMT
Response: TVFS
Response: MLST modify*;type*;unique*;size*;UNIX.mode*;UNIX.owner*;UNIX.group*;
Response: MLSD modify*;type*;unique*;size*;UNIX.mode*;UNIX.owner*;UNIX.group*;
Response: UTF8
07:59:45.020	Info	Response: 211 End. [76ms]
07:59:45.020	Info	Status:   Text encoding: System.Text.UTF8Encoding+UTF8EncodingSealed
07:59:45.020	Info	Command:  OPTS UTF8 ON
07:59:45.021	Verbose	Status:   Waiting for response to: OPTS UTF8 ON
07:59:45.089	Info	Response: 200 OK, UTF-8 enabled [68ms]
07:59:45.090	Info	Command:  SYST
07:59:45.090	Verbose	Status:   Waiting for response to: SYST
07:59:45.160	Info	Response: 215 UNIX Type: L8 [69ms]
07:59:45.161	Verbose	Status:   Active ServerHandler is: None
07:59:45.161	Verbose	Status:   Listing parser set to: Machine
07:59:45.161	Info	Command:  PWD
07:59:45.162	Verbose	Status:   Waiting for response to: PWD
07:59:45.233	Info	Response: 257 "/" is current directory. [71ms]
07:59:45.236	Verbose	>         UploadFile("C:\temp\uploadme-87E0D712.7z", "/backup/2023-11-27/uploadme-87E0D712.7z", Resume, True, Retry)
07:59:45.238	Verbose	>         FileExists("/backup/2023-11-27/uploadme-87E0D712.7z")
07:59:45.238	Info	Command:  SIZE /backup/2023-11-27/uploadme-87E0D712.7z
07:59:45.238	Verbose	Status:   Waiting for response to: SIZE /backup/2023-11-27/uploadme-87E0D712.7z
07:59:45.306	Info	Response: 550 /backup/2023-11-27/uploadme-87E0D712.7z: No such file or direcotry. [67ms]
07:59:45.308	Verbose	>         DirectoryExists("/backup/2023-11-27")
07:59:45.309	Info	Command:  CWD /backup/2023-11-27
07:59:45.309	Verbose	Status:   Waiting for response to: CWD /backup/2023-11-27
07:59:45.379	Info	Response: 550 /backup/2023-11-27: No such file or directory. [69ms]
07:59:45.380	Verbose	>         CreateDirectory("/backup/2023-11-27", True)
07:59:45.380	Verbose	>         DirectoryExists("/backup")
07:59:45.380	Info	Command:  CWD /backup
07:59:45.381	Verbose	Status:   Waiting for response to: CWD /backup
07:59:45.473	Info	Response: 250 CWD command successful. [92ms]
07:59:45.474	Info	Command:  CWD /
07:59:45.474	Verbose	Status:   Waiting for response to: CWD /
07:59:45.542	Info	Response: 250 CWD command successful. [67ms]
07:59:45.542	Verbose	Status:   CreateDirectory /backup/2023-11-27
07:59:45.542	Info	Command:  MKD /backup/2023-11-27
07:59:45.543	Verbose	Status:   Waiting for response to: MKD /backup/2023-11-27
07:59:45.622	Info	Response: 257 "/backup/2023-11-27" directory created. [78ms]
07:59:45.623	Verbose	>         OpenWrite("/backup/2023-11-27/uploadme-87E0D712.7z", Binary)
07:59:45.624	Info	Command:  TYPE I
07:59:45.624	Verbose	Status:   Waiting for response to: TYPE I
07:59:45.692	Info	Response: 200 Type set to I. [68ms]
07:59:45.693	Verbose	>         OpenDataStreamAsync("STOR /backup/2023-11-27/uploadme-87E0D712.7z", 0)
07:59:45.694	Verbose	>         OpenPassiveDataStreamAsync(EPSV, "STOR /backup/2023-11-27/uploadme-87E0D712.7z", 0)
07:59:45.694	Info	Command:  EPSV
07:59:45.694	Verbose	Status:   Waiting for response to: EPSV
07:59:45.764	Info	Response: 229 Entering Extended Passive Mode (|||55537|) [69ms]
07:59:45.766	Info	Status:   Connecting to IP #1= ***:55537
07:59:45.768	Info	Command:  STOR /backup/2023-11-27/uploadme-87E0D712.7z
07:59:45.768	Verbose	Status:   Waiting for response to: STOR /backup/2023-11-27/uploadme-87E0D712.7z
07:59:45.949	Info	Response: 150 Opening BINARY mode SSL data connection for '/backup/2023-11-27/uploadme-87E0D712.7z'. [180ms]
07:59:45.950	Warn	Warning:  SSL Buffering disabled because of .NET 5.0 and later
07:59:46.093	Info	Status:   FTPS authentication successful, lib = .NET SslStream, cipher suite = Tls13 (Aes256, TLS_AES_256_GCM_SHA384, None, 0) [143ms]
07:59:46.158	Verbose	Status:   Uploaded 2699547 bytes
07:59:46.158	Verbose	Status:   Closing/Disposing FtpSocketStream(data connection)
07:59:46.159	Verbose	Status:   Waiting for response to: STOR /backup/2023-11-27/uploadme-87E0D712.7z
07:59:46.250	Info	Response: 226 Transfer complete. [481ms]
07:59:46.250	Info	Status:   File Verification: PASS
07:59:46.251	requesting file size
07:59:46.251	Verbose	>         GetFileSize("/backup/2023-11-27/uploadme-87E0D712.7z", -1)
07:59:46.251	Info	Command:  SIZE /backup/2023-11-27/uploadme-87E0D712.7z
07:59:46.251	Verbose	Status:   Waiting for response to: SIZE /backup/2023-11-27/uploadme-87E0D712.7z
07:59:46.319	Info	Response: 213 114541 [67ms]
07:59:46.323	got 114541
07:59:46.323	Info	Command:  QUIT
07:59:46.324	Verbose	Status:   Waiting for response to: QUIT
07:59:46.392	Info	Response: 221 Goodbye. You uploaded 111.86 KB and downloaded 0 bytes. [68ms]
07:59:46.395	Verbose	Status:   Closing/Disposing FtpSocketStream(control connection)

2nd:
07:59:46.655	Verbose	>         Connect(False)
07:59:46.656	Verbose	Status:   FluentFTP <IP_ADDRESS>(.NET 6.0)
07:59:46.656	Info	Status:   Connecting to IP #1= ***:21
07:59:46.658	Verbose	Status:   Waiting for a response
07:59:46.816	Info	Response: 220 oneNAS FTP server ready. [492ms]
07:59:46.817	Info	Command:  AUTH TLS
07:59:46.817	Verbose	Status:   Waiting for response to: AUTH TLS
07:59:46.885	Info	Response: 234 AUTH TLS command successful. [68ms]
07:59:46.885	Warn	Warning:  SSL Buffering disabled because of .NET 5.0 and later
07:59:47.033	Info	Status:   FTPS authentication successful, lib = .NET SslStream, cipher suite = Tls13 (Aes256, TLS_AES_256_GCM_SHA384, None, 0) [147ms]
07:59:47.033	Info	Command:  USER ***
07:59:47.033	Verbose	Status:   Waiting for response to: USER ***
07:59:47.103	Info	Response: 331 Password required for ***. [70ms]
07:59:47.104	Info	Command:  PASS ***
07:59:47.105	Verbose	Status:   Waiting for response to: PASS ***
07:59:47.193	Info	Response: 230 User *** logged in. [88ms]
07:59:47.194	Info	Command:  PBSZ 0
07:59:47.194	Verbose	Status:   Waiting for response to: PBSZ 0
07:59:47.273	Info	Response: 200 PBSZ command successful (PBSZ=0). [78ms]
07:59:47.274	Info	Command:  PROT P
07:59:47.274	Verbose	Status:   Waiting for response to: PROT P
07:59:47.345	Info	Response: 200 Protection level set to Private. [71ms]
07:59:47.346	Info	Command:  FEAT
07:59:47.346	Verbose	Status:   Waiting for response to: FEAT
07:59:47.417	Verbose	Response: 211- Extensions supported:
Response: AUTH TLS
Response: PBSZ
Response: PROT
Response: CCC
Response: SIZE
Response: MDTM
Response: REST STREAM
Response: MFMT
Response: TVFS
Response: MLST modify*;type*;unique*;size*;UNIX.mode*;UNIX.owner*;UNIX.group*;
Response: MLSD modify*;type*;unique*;size*;UNIX.mode*;UNIX.owner*;UNIX.group*;
Response: UTF8
07:59:47.418	Info	Response: 211 End. [71ms]
07:59:47.418	Info	Status:   Text encoding: System.Text.UTF8Encoding+UTF8EncodingSealed
07:59:47.418	Info	Command:  OPTS UTF8 ON
07:59:47.418	Verbose	Status:   Waiting for response to: OPTS UTF8 ON
07:59:47.496	Info	Response: 200 OK, UTF-8 enabled [77ms]
07:59:47.496	Info	Command:  SYST
07:59:47.497	Verbose	Status:   Waiting for response to: SYST
07:59:47.564	Info	Response: 215 UNIX Type: L8 [67ms]
07:59:47.565	Verbose	Status:   Active ServerHandler is: None
07:59:47.566	Verbose	Status:   Listing parser set to: Machine
07:59:47.566	Info	Command:  PWD
07:59:47.567	Verbose	Status:   Waiting for response to: PWD
07:59:47.637	Info	Response: 257 "/" is current directory. [70ms]
07:59:47.638	Verbose	>         UploadFile("C:\temp\uploadme-87E0D712.7z", "/backup/2023-11-27/uploadme-87E0D712.7z", Resume, True, Retry)
07:59:47.638	Verbose	>         FileExists("/backup/2023-11-27/uploadme-87E0D712.7z")
07:59:47.638	Info	Command:  SIZE /backup/2023-11-27/uploadme-87E0D712.7z
07:59:47.639	Verbose	Status:   Waiting for response to: SIZE /backup/2023-11-27/uploadme-87E0D712.7z
07:59:47.709	Info	Response: 213 114541 [70ms]
07:59:47.709	Verbose	>         GetFileSize("/backup/2023-11-27/uploadme-87E0D712.7z", 0)
07:59:47.709	Info	Command:  SIZE /backup/2023-11-27/uploadme-87E0D712.7z
07:59:47.710	Verbose	Status:   Waiting for response to: SIZE /backup/2023-11-27/uploadme-87E0D712.7z
07:59:47.782	Info	Response: 213 114541 [71ms]
07:59:47.782	Verbose	>         OpenAppend("/backup/2023-11-27/uploadme-87E0D712.7z", Binary)
07:59:47.783	Info	Command:  TYPE I
07:59:47.784	Verbose	Status:   Waiting for response to: TYPE I
07:59:47.851	Info	Response: 200 Type set to I. [67ms]
07:59:47.853	Verbose	>         OpenDataStreamAsync("APPE /backup/2023-11-27/uploadme-87E0D712.7z", 0)
07:59:47.853	Verbose	>         OpenPassiveDataStreamAsync(EPSV, "APPE /backup/2023-11-27/uploadme-87E0D712.7z", 0)
07:59:47.854	Info	Command:  EPSV
07:59:47.855	Verbose	Status:   Waiting for response to: EPSV
07:59:47.927	Info	Response: 229 Entering Extended Passive Mode (|||55536|) [72ms]
07:59:47.927	Info	Status:   Connecting to IP #1= ***:55536
07:59:47.928	Info	Command:  APPE /backup/2023-11-27/uploadme-87E0D712.7z
07:59:47.928	Verbose	Status:   Waiting for response to: APPE /backup/2023-11-27/uploadme-87E0D712.7z
07:59:48.134	Info	Response: 150 Opening BINARY mode SSL data connection for '/backup/2023-11-27/uploadme-87E0D712.7z'. [205ms]
07:59:48.135	Warn	Warning:  SSL Buffering disabled because of .NET 5.0 and later
07:59:48.281	Info	Status:   FTPS authentication successful, lib = .NET SslStream, cipher suite = Tls13 (Aes256, TLS_AES_256_GCM_SHA384, None, 0) [146ms]
07:59:48.343	Verbose	Status:   Uploaded 2699547 bytes
07:59:48.344	Verbose	Status:   Closing/Disposing FtpSocketStream(data connection)
07:59:48.345	Verbose	Status:   Waiting for response to: APPE /backup/2023-11-27/uploadme-87E0D712.7z
07:59:48.438	Info	Response: 226 Transfer complete. [509ms]
07:59:48.438	Info	Status:   File Verification: PASS
07:59:48.439	requesting file size
07:59:48.439	Verbose	>         GetFileSize("/backup/2023-11-27/uploadme-87E0D712.7z", -1)
07:59:48.440	Info	Command:  SIZE /backup/2023-11-27/uploadme-87E0D712.7z
07:59:48.440	Verbose	Status:   Waiting for response to: SIZE /backup/2023-11-27/uploadme-87E0D712.7z
07:59:48.517	Info	Response: 213 212747 [76ms]
07:59:48.518	got 212747
07:59:48.518	Info	Command:  QUIT
07:59:48.518	Verbose	Status:   Waiting for response to: QUIT
07:59:48.587	Info	Response: 221 Goodbye. You uploaded 95.90 KB and downloaded 0 bytes. [69ms]
07:59:48.587	Verbose	Status:   Closing/Disposing FtpSocketStream(control connection)

attempt 3:
07:59:48.963	Verbose	>         Connect(False)
07:59:48.963	Verbose	Status:   FluentFTP <IP_ADDRESS>(.NET 6.0)
07:59:48.963	Info	Status:   Connecting to IP #1= ***:21
07:59:48.964	Verbose	Status:   Waiting for a response
07:59:49.138	Info	Response: 220 oneNAS FTP server ready. [620ms]
07:59:49.139	Info	Command:  AUTH TLS
07:59:49.139	Verbose	Status:   Waiting for response to: AUTH TLS
07:59:49.210	Info	Response: 234 AUTH TLS command successful. [70ms]
07:59:49.210	Warn	Warning:  SSL Buffering disabled because of .NET 5.0 and later
07:59:49.414	Info	Status:   FTPS authentication successful, lib = .NET SslStream, cipher suite = Tls13 (Aes256, TLS_AES_256_GCM_SHA384, None, 0) [204ms]
07:59:49.415	Info	Command:  USER ***
07:59:49.415	Verbose	Status:   Waiting for response to: USER ***
07:59:49.484	Info	Response: 331 Password required for ***. [69ms]
07:59:49.485	Info	Command:  PASS ***
07:59:49.486	Verbose	Status:   Waiting for response to: PASS ***
07:59:49.577	Info	Response: 230 User *** logged in. [91ms]
07:59:49.578	Info	Command:  PBSZ 0
07:59:49.578	Verbose	Status:   Waiting for response to: PBSZ 0
07:59:49.647	Info	Response: 200 PBSZ command successful (PBSZ=0). [68ms]
07:59:49.648	Info	Command:  PROT P
07:59:49.648	Verbose	Status:   Waiting for response to: PROT P
07:59:49.720	Info	Response: 200 Protection level set to Private. [72ms]
07:59:49.721	Info	Command:  FEAT
07:59:49.721	Verbose	Status:   Waiting for response to: FEAT
07:59:49.794	Verbose	Response: 211- Extensions supported:
Response: AUTH TLS
Response: PBSZ
Response: PROT
Response: CCC
Response: SIZE
Response: MDTM
Response: REST STREAM
Response: MFMT
Response: TVFS
Response: MLST modify*;type*;unique*;size*;UNIX.mode*;UNIX.owner*;UNIX.group*;
Response: MLSD modify*;type*;unique*;size*;UNIX.mode*;UNIX.owner*;UNIX.group*;
Response: UTF8
07:59:49.794	Info	Response: 211 End. [73ms]
07:59:49.795	Info	Status:   Text encoding: System.Text.UTF8Encoding+UTF8EncodingSealed
07:59:49.795	Info	Command:  OPTS UTF8 ON
07:59:49.795	Verbose	Status:   Waiting for response to: OPTS UTF8 ON
07:59:49.866	Info	Response: 200 OK, UTF-8 enabled [71ms]
07:59:49.866	Info	Command:  SYST
07:59:49.867	Verbose	Status:   Waiting for response to: SYST
07:59:49.939	Info	Response: 215 UNIX Type: L8 [71ms]
07:59:49.939	Verbose	Status:   Active ServerHandler is: None
07:59:49.939	Verbose	Status:   Listing parser set to: Machine
07:59:49.939	Info	Command:  PWD
07:59:49.940	Verbose	Status:   Waiting for response to: PWD
07:59:50.010	Info	Response: 257 "/" is current directory. [70ms]
07:59:50.010	Verbose	>         UploadFile("C:\temp\uploadme-87E0D712.7z", "/backup/2023-11-27/uploadme-87E0D712.7z", Resume, True, Retry)
07:59:50.010	Verbose	>         FileExists("/backup/2023-11-27/uploadme-87E0D712.7z")
07:59:50.010	Info	Command:  SIZE /backup/2023-11-27/uploadme-87E0D712.7z
07:59:50.011	Verbose	Status:   Waiting for response to: SIZE /backup/2023-11-27/uploadme-87E0D712.7z
07:59:50.089	Info	Response: 213 212747 [78ms]
07:59:50.090	Verbose	>         GetFileSize("/backup/2023-11-27/uploadme-87E0D712.7z", 0)
07:59:50.090	Info	Command:  SIZE /backup/2023-11-27/uploadme-87E0D712.7z
07:59:50.091	Verbose	Status:   Waiting for response to: SIZE /backup/2023-11-27/uploadme-87E0D712.7z
07:59:50.165	Info	Response: 213 212747 [74ms]
07:59:50.166	Verbose	>         OpenAppend("/backup/2023-11-27/uploadme-87E0D712.7z", Binary)
07:59:50.166	Info	Command:  TYPE I
07:59:50.166	Verbose	Status:   Waiting for response to: TYPE I
07:59:50.240	Info	Response: 200 Type set to I. [74ms]
07:59:50.241	Verbose	>         OpenDataStreamAsync("APPE /backup/2023-11-27/uploadme-87E0D712.7z", 0)
07:59:50.241	Verbose	>         OpenPassiveDataStreamAsync(EPSV, "APPE /backup/2023-11-27/uploadme-87E0D712.7z", 0)
07:59:50.241	Info	Command:  EPSV
07:59:50.241	Verbose	Status:   Waiting for response to: EPSV
07:59:50.311	Info	Response: 229 Entering Extended Passive Mode (|||55537|) [69ms]
07:59:50.311	Info	Status:   Connecting to IP #1= ***:55537
07:59:50.312	Info	Command:  APPE /backup/2023-11-27/uploadme-87E0D712.7z
07:59:50.312	Verbose	Status:   Waiting for response to: APPE /backup/2023-11-27/uploadme-87E0D712.7z
07:59:50.472	Info	Response: 150 Opening BINARY mode SSL data connection for '/backup/2023-11-27/uploadme-87E0D712.7z'. [159ms]
07:59:50.472	Warn	Warning:  SSL Buffering disabled because of .NET 5.0 and later
07:59:50.611	Info	Status:   FTPS authentication successful, lib = .NET SslStream, cipher suite = Tls13 (Aes256, TLS_AES_256_GCM_SHA384, None, 0) [138ms]
07:59:50.675	Verbose	Status:   Uploaded 2699547 bytes
07:59:50.676	Verbose	Status:   Closing/Disposing FtpSocketStream(data connection)
07:59:50.677	Verbose	Status:   Waiting for response to: APPE /backup/2023-11-27/uploadme-87E0D712.7z
07:59:50.779	Info	Response: 226 Transfer complete. [466ms]
07:59:50.780	Info	Status:   File Verification: PASS
07:59:50.781	requesting file size
07:59:50.782	Verbose	>         GetFileSize("/backup/2023-11-27/uploadme-87E0D712.7z", -1)
07:59:50.782	Info	Command:  SIZE /backup/2023-11-27/uploadme-87E0D712.7z
07:59:50.783	Verbose	Status:   Waiting for response to: SIZE /backup/2023-11-27/uploadme-87E0D712.7z
07:59:50.852	Info	Response: 213 343819 [69ms]
07:59:50.853	got 343819
07:59:50.853	Info	Command:  QUIT
07:59:50.854	Verbose	Status:   Waiting for response to: QUIT
07:59:50.931	Info	Response: 221 Goodbye. You uploaded 128.00 KB and downloaded 0 bytes. [76ms]
07:59:50.931	Verbose	Status:   Closing/Disposing FtpSocketStream(control connection)

skipped a bunch!
attempt 14:
08:01:32.548	Verbose	>         Connect(False)
08:01:32.549	Verbose	Status:   FluentFTP <IP_ADDRESS>(.NET 6.0)
08:01:32.550	Info	Status:   Connecting to IP #1= ***:21
08:01:32.551	Verbose	Status:   Waiting for a response
08:01:32.717	Info	Response: 220 oneNAS FTP server ready. [1.344s]
08:01:32.718	Info	Command:  AUTH TLS
08:01:32.718	Verbose	Status:   Waiting for response to: AUTH TLS
08:01:32.787	Info	Response: 234 AUTH TLS command successful. [68ms]
08:01:32.788	Warn	Warning:  SSL Buffering disabled because of .NET 5.0 and later
08:01:32.942	Info	Status:   FTPS authentication successful, lib = .NET SslStream, cipher suite = Tls13 (Aes256, TLS_AES_256_GCM_SHA384, None, 0) [154ms]
08:01:32.943	Info	Command:  USER ***
08:01:32.943	Verbose	Status:   Waiting for response to: USER ***
08:01:33.011	Info	Response: 331 Password required for ***. [68ms]
08:01:33.012	Info	Command:  PASS ***
08:01:33.012	Verbose	Status:   Waiting for response to: PASS ***
08:01:33.098	Info	Response: 230 User *** logged in. [86ms]
08:01:33.099	Info	Command:  PBSZ 0
08:01:33.099	Verbose	Status:   Waiting for response to: PBSZ 0
08:01:33.170	Info	Response: 200 PBSZ command successful (PBSZ=0). [70ms]
08:01:33.170	Info	Command:  PROT P
08:01:33.171	Verbose	Status:   Waiting for response to: PROT P
08:01:33.240	Info	Response: 200 Protection level set to Private. [69ms]
08:01:33.240	Info	Command:  FEAT
08:01:33.241	Verbose	Status:   Waiting for response to: FEAT
08:01:33.309	Verbose	Response: 211- Extensions supported:
Response: AUTH TLS
Response: PBSZ
Response: PROT
Response: CCC
Response: SIZE
Response: MDTM
Response: REST STREAM
Response: MFMT
Response: TVFS
Response: MLST modify*;type*;unique*;size*;UNIX.mode*;UNIX.owner*;UNIX.group*;
Response: MLSD modify*;type*;unique*;size*;UNIX.mode*;UNIX.owner*;UNIX.group*;
Response: UTF8
08:01:33.310	Info	Response: 211 End. [69ms]
08:01:33.311	Info	Status:   Text encoding: System.Text.UTF8Encoding+UTF8EncodingSealed
08:01:33.311	Info	Command:  OPTS UTF8 ON
08:01:33.311	Verbose	Status:   Waiting for response to: OPTS UTF8 ON
08:01:33.378	Info	Response: 200 OK, UTF-8 enabled [66ms]
08:01:33.378	Info	Command:  SYST
08:01:33.378	Verbose	Status:   Waiting for response to: SYST
08:01:33.445	Info	Response: 215 UNIX Type: L8 [66ms]
08:01:33.446	Verbose	Status:   Active ServerHandler is: None
08:01:33.446	Verbose	Status:   Listing parser set to: Machine
08:01:33.446	Info	Command:  PWD
08:01:33.446	Verbose	Status:   Waiting for response to: PWD
08:01:33.516	Info	Response: 257 "/" is current directory. [69ms]
08:01:33.516	Verbose	>         UploadFile("C:\temp\uploadme-87E0D712.7z", "/backup/2023-11-27/uploadme-87E0D712.7z", Resume, True, Retry)
08:01:33.517	Verbose	>         FileExists("/backup/2023-11-27/uploadme-87E0D712.7z")
08:01:33.517	Info	Command:  SIZE /backup/2023-11-27/uploadme-87E0D712.7z
08:01:33.517	Verbose	Status:   Waiting for response to: SIZE /backup/2023-11-27/uploadme-87E0D712.7z
08:01:33.592	Info	Response: 213 949390 [74ms]
08:01:33.592	Verbose	>         GetFileSize("/backup/2023-11-27/uploadme-87E0D712.7z", 0)
08:01:33.593	Info	Command:  SIZE /backup/2023-11-27/uploadme-87E0D712.7z
08:01:33.593	Verbose	Status:   Waiting for response to: SIZE /backup/2023-11-27/uploadme-87E0D712.7z
08:01:33.662	Info	Response: 213 949390 [68ms]
08:01:33.663	Verbose	>         OpenAppend("/backup/2023-11-27/uploadme-87E0D712.7z", Binary)
08:01:33.663	Info	Command:  TYPE I
08:01:33.664	Verbose	Status:   Waiting for response to: TYPE I
08:01:33.733	Info	Response: 200 Type set to I. [69ms]
08:01:33.733	Verbose	>         OpenDataStreamAsync("APPE /backup/2023-11-27/uploadme-87E0D712.7z", 0)
08:01:33.733	Verbose	>         OpenPassiveDataStreamAsync(EPSV, "APPE /backup/2023-11-27/uploadme-87E0D712.7z", 0)
08:01:33.734	Info	Command:  EPSV
08:01:33.734	Verbose	Status:   Waiting for response to: EPSV
08:01:33.802	Info	Response: 229 Entering Extended Passive Mode (|||55537|) [67ms]
08:01:33.803	Info	Status:   Connecting to IP #1= ***:55537
08:01:33.804	Info	Command:  APPE /backup/2023-11-27/uploadme-87E0D712.7z
08:01:33.804	Verbose	Status:   Waiting for response to: APPE /backup/2023-11-27/uploadme-87E0D712.7z
08:01:33.969	Info	Response: 150 Opening BINARY mode SSL data connection for '/backup/2023-11-27/uploadme-87E0D712.7z'. [164ms]
08:01:33.970	Warn	Warning:  SSL Buffering disabled because of .NET 5.0 and later
08:01:34.109	Info	Status:   FTPS authentication successful, lib = .NET SslStream, cipher suite = Tls13 (Aes256, TLS_AES_256_GCM_SHA384, None, 0) [138ms]
08:01:34.115	Verbose	Status:   Uploaded 2699547 bytes
08:01:34.115	Verbose	Status:   Closing/Disposing FtpSocketStream(data connection)
08:01:34.116	Verbose	Status:   Waiting for response to: APPE /backup/2023-11-27/uploadme-87E0D712.7z
08:01:34.273	Info	Response: 226 Transfer complete. [469ms]
08:01:34.274	Info	Status:   File Verification: PASS
08:01:34.274	requesting file size
08:01:34.275	Verbose	>         GetFileSize("/backup/2023-11-27/uploadme-87E0D712.7z", -1)
08:01:34.275	Info	Command:  SIZE /backup/2023-11-27/uploadme-87E0D712.7z
08:01:34.276	Verbose	Status:   Waiting for response to: SIZE /backup/2023-11-27/uploadme-87E0D712.7z
08:01:34.347	Info	Response:<PHONE_NUMBER> [71ms]
08:01:34.348	got 1063931
08:01:34.348	Info	Command:  QUIT
08:01:34.348	Verbose	Status:   Waiting for response to: QUIT
08:01:34.416	Info	Response: 221 Goodbye. You uploaded 111.86 KB and downloaded 0 bytes. [67ms]
08:01:34.416	Verbose	Status:   Closing/Disposing FtpSocketStream(control connection)

final upload:
08:05:26.717	Verbose	>         Connect(False)
08:05:26.718	Verbose	Status:   FluentFTP <IP_ADDRESS>(.NET 6.0)
08:05:26.719	Info	Status:   Connecting to IP #1= ***:21
08:05:26.720	Verbose	Status:   Waiting for a response
08:05:26.881	Info	Response: 220 oneNAS FTP server ready. [17.701s]
08:05:26.882	Info	Command:  AUTH TLS
08:05:26.882	Verbose	Status:   Waiting for response to: AUTH TLS
08:05:26.947	Info	Response: 234 AUTH TLS command successful. [65ms]
08:05:26.948	Warn	Warning:  SSL Buffering disabled because of .NET 5.0 and later
08:05:27.101	Info	Status:   FTPS authentication successful, lib = .NET SslStream, cipher suite = Tls13 (Aes256, TLS_AES_256_GCM_SHA384, None, 0) [153ms]
08:05:27.102	Info	Command:  USER ***
08:05:27.103	Verbose	Status:   Waiting for response to: USER ***
08:05:27.189	Info	Response: 331 Password required for ***. [86ms]
08:05:27.190	Info	Command:  PASS ***
08:05:27.190	Verbose	Status:   Waiting for response to: PASS ***
08:05:27.279	Info	Response: 230 User *** logged in. [88ms]
08:05:27.279	Info	Command:  PBSZ 0
08:05:27.280	Verbose	Status:   Waiting for response to: PBSZ 0
08:05:27.350	Info	Response: 200 PBSZ command successful (PBSZ=0). [69ms]
08:05:27.350	Info	Command:  PROT P
08:05:27.351	Verbose	Status:   Waiting for response to: PROT P
08:05:27.419	Info	Response: 200 Protection level set to Private. [68ms]
08:05:27.420	Info	Command:  FEAT
08:05:27.420	Verbose	Status:   Waiting for response to: FEAT
08:05:27.492	Verbose	Response: 211- Extensions supported:
Response: AUTH TLS
Response: PBSZ
Response: PROT
Response: CCC
Response: SIZE
Response: MDTM
Response: REST STREAM
Response: MFMT
Response: TVFS
Response: MLST modify*;type*;unique*;size*;UNIX.mode*;UNIX.owner*;UNIX.group*;
Response: MLSD modify*;type*;unique*;size*;UNIX.mode*;UNIX.owner*;UNIX.group*;
Response: UTF8
08:05:27.493	Info	Response: 211 End. [72ms]
08:05:27.493	Info	Status:   Text encoding: System.Text.UTF8Encoding+UTF8EncodingSealed
08:05:27.494	Info	Command:  OPTS UTF8 ON
08:05:27.494	Verbose	Status:   Waiting for response to: OPTS UTF8 ON
08:05:27.564	Info	Response: 200 OK, UTF-8 enabled [69ms]
08:05:27.565	Info	Command:  SYST
08:05:27.565	Verbose	Status:   Waiting for response to: SYST
08:05:27.636	Info	Response: 215 UNIX Type: L8 [70ms]
08:05:27.637	Verbose	Status:   Active ServerHandler is: None
08:05:27.637	Verbose	Status:   Listing parser set to: Machine
08:05:27.637	Info	Command:  PWD
08:05:27.638	Verbose	Status:   Waiting for response to: PWD
08:05:27.712	Info	Response: 257 "/" is current directory. [74ms]
08:05:27.713	Verbose	>         UploadFile("C:\temp\uploadme-87E0D712.7z", "/backup/2023-11-27/uploadme-87E0D712.7z", Resume, True, Retry)
08:05:27.713	Verbose	>         FileExists("/backup/2023-11-27/uploadme-87E0D712.7z")
08:05:27.713	Info	Command:  SIZE /backup/2023-11-27/uploadme-87E0D712.7z
08:05:27.713	Verbose	Status:   Waiting for response to: SIZE /backup/2023-11-27/uploadme-87E0D712.7z
08:05:27.787	Info	Response:<PHONE_NUMBER> [73ms]
08:05:27.788	Verbose	>         GetFileSize("/backup/2023-11-27/uploadme-87E0D712.7z", 0)
08:05:27.788	Info	Command:  SIZE /backup/2023-11-27/uploadme-87E0D712.7z
08:05:27.788	Verbose	Status:   Waiting for response to: SIZE /backup/2023-11-27/uploadme-87E0D712.7z
08:05:27.862	Info	Response:<PHONE_NUMBER> [73ms]
08:05:27.863	Verbose	>         OpenAppend("/backup/2023-11-27/uploadme-87E0D712.7z", Binary)
08:05:27.863	Info	Command:  TYPE I
08:05:27.864	Verbose	Status:   Waiting for response to: TYPE I
08:05:27.939	Info	Response: 200 Type set to I. [75ms]
08:05:27.940	Verbose	>         OpenDataStreamAsync("APPE /backup/2023-11-27/uploadme-87E0D712.7z", 0)
08:05:27.941	Verbose	>         OpenPassiveDataStreamAsync(EPSV, "APPE /backup/2023-11-27/uploadme-87E0D712.7z", 0)
08:05:27.941	Info	Command:  EPSV
08:05:27.941	Verbose	Status:   Waiting for response to: EPSV
08:05:28.017	Info	Response: 229 Entering Extended Passive Mode (|||55536|) [75ms]
08:05:28.018	Info	Status:   Connecting to IP #1= ***:55536
08:05:28.019	Info	Command:  APPE /backup/2023-11-27/uploadme-87E0D712.7z
08:05:28.019	Verbose	Status:   Waiting for response to: APPE /backup/2023-11-27/uploadme-87E0D712.7z
08:05:28.199	Info	Response: 150 Opening BINARY mode SSL data connection for '/backup/2023-11-27/uploadme-87E0D712.7z'. [179ms]
08:05:28.200	Warn	Warning:  SSL Buffering disabled because of .NET 5.0 and later
08:05:28.351	Info	Status:   FTPS authentication successful, lib = .NET SslStream, cipher suite = Tls13 (Aes256, TLS_AES_256_GCM_SHA384, None, 0) [151ms]
08:05:28.353	Verbose	Status:   Uploaded 2699547 bytes
08:05:28.353	Verbose	Status:   Closing/Disposing FtpSocketStream(data connection)
08:05:28.354	Verbose	Status:   Waiting for response to: APPE /backup/2023-11-27/uploadme-87E0D712.7z
08:05:28.422	Info	Response: 226 Transfer complete. [402ms]
08:05:28.423	Info	Status:   File Verification: PASS
08:05:28.423	requesting file size
08:05:28.423	Verbose	>         GetFileSize("/backup/2023-11-27/uploadme-87E0D712.7z", -1)
08:05:28.423	Info	Command:  SIZE /backup/2023-11-27/uploadme-87E0D712.7z
08:05:28.423	Verbose	Status:   Waiting for response to: SIZE /backup/2023-11-27/uploadme-87E0D712.7z
08:05:28.495	Info	Response:<PHONE_NUMBER> [71ms]
08:05:28.495	got 2699547
08:05:28.496	Info	Command:  QUIT
08:05:28.496	Verbose	Status:   Waiting for response to: QUIT
08:05:28.565	Info	Response: 221 Goodbye. You uploaded 14.76 KB and downloaded 0 bytes. [69ms]
08:05:28.566	Verbose	Status:   Closing/Disposing FtpSocketStream(control connection)
08:05:28.568	Verbose	>         Dispose()
08:05:28.568	Verbose	Status:   Disposing FtpClient object...
08:05:28.568	Verbose	Status:   Closing/Disposing FtpSocketStream(control connection)

So,
Local file size to upload: 2699547, on destination file does not exist.
Attempt 1: Uploaded 2699547 bytes, resulting size:  114541, delta = 11541
Attempt 2: Uploaded 2699547 bytes, resulting size:  212747, delta = 98206
Attempt 3: Uploaded 2699547 bytes, resulting size:  343819, delta = 131072
Attempt 4: Uploaded 2699547 bytes, resulting size:  2699547, delta = 2355728

That destroys any theory that always the same chunks get uploaded on each attempt. The deltas are more random and the last attempt actually shows a big chunk getting uploaded.
At least these repeated attempts are now working. I think you would even not have to make a new client each time, that should now work also.
How is this server connection routed from your client? Any stateful ( = hateful ) firewalls in between?
FluentFTP seems to be sending the entire file down the line and gets a successful message from the server (226 Transfer complete), but the server seems to have received only a first fragment.

Uhhmmmm me doing a wireshark trace is not going to be easy... I'm transfering multiple gigabytes worth of files...

Well, to really see what is going on, one would like to see the traffic (client side first) and really only for the first attempt would be necessary.

So, although we have not found out why the transfers are being interrupted somewhere down the line, you have implemented a retry scheme that works after a few bugs were fixed. Thanks for helping us to find and debug them.
I suppose we can close this - as I don't think this is a FluenFTP code problem.


MWPW-154448: Content should be in a data table but is not

This will enable the table accessibility

Resolves:

MWPW-154448
DOTCOM-124917

Test URLs:
Milo

Before: https://main--milo--adobecom.hlx.page/drafts/siva/124917/table-example?martech=off

After: https://mwpw-154448--milo--sivasadobe.hlx.page/drafts/siva/124917/table-example?martech=off

Before: https://main--milo--adobecom.hlx.page/docs/authoring/tables?martech=off

After: https://mwpw-154448--milo--sivasadobe.hlx.page/docs/authoring/tables?martech=off

CC

Before: https://main--cc--adobecom.hlx.live/products/illustrator/plans?martech=off
After: https://main--cc--adobecom.hlx.live/products/illustrator/plans?martech=off&milolibs=mwpw-154448--milo--sivasadobe

@sivasadobe Could you please fix the unit tests for this PR?

@sivasadobe Could you please fix the unit tests for this PR?

Fixed.
Could you review again.

I have verified the PR on the Chrome browser.
Content present below 'Apps' text is marked as data table.
Attached evidence in Jira - https://jira.corp.adobe.com/browse/MWPW-156659


Translations - Arabic

For anybody wishing to contribute to the translations:
https://github.com/OriginProtocol/company-website/blob/master/translations/ar/LC_MESSAGES/messages.po
You add the translated-versions under msgstr ""
Example:
msgid "Hello"
msgstr "Bonjour"

See the German translation as an example:
https://github.com/OriginProtocol/company-website/blob/master/translations/de/LC_MESSAGES/messages.po

This was done by "m.alqattan".


Support Chunked Encoding in httpd_req_recv (IDFGH-10533)

Is your feature request related to a problem?
I need to have a full duplex HTTP communication channel between the ESP httpd server and javascript on a website. One solution is to have both the transfer and receive use the Chunked Encoding, but the ESP HTTP server does not support receiving in chunks.
Describe the solution you'd like.
I would like httpd_req_recv to implement Chunked Encoding.
Describe alternatives you've considered.

I tried having the website send its payload normally and receive concurrent messages with chunked encoding, but the fetch API blocks until the whole payload has been transferred.
I tried having the website send its payload with one HTTP request and receive concurrent messages on another one, but the ESP HTTP server doesn't support concurrent http requests.
I know that websockets would work but plain HTTP would be more convenient.

Additional context.
No response

@xjzi Yes, we not support receive chunk data in esp_http_server component now. We will evaluate this function request internal first.

We will evaluate this function request internal first.

@ESP-YJM
The status switched back to Opened after in "Selected for Development" for 10 Months.
How is the progress now?

@mahavirj  Could you please help update the status?


Typo in casing

The table c is lowercase, so:
/*+ RANGE_JOIN(C, 500) */ *
Should be:
/*+ RANGE_JOIN(c, 500) */ *
Not a biggie, but it triggers my OCD :)

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 766e3fdd-3427-8a47-2755-403a912e9481
Version Independent ID: 2fe6a7b8-ed62-cbec-8351-21d3a4132635
Content: Range Join optimization - Azure Databricks
Content Source: databricks/delta/join-performance/range-join.md
Service: azure-databricks
GitHub Login: @mamccrea
Microsoft Alias: mamccrea

@Fokko,thank you for reaching out. We are looking into this and would get back to you soon on this thread.

I have updated the doc. Please allow a few days for the changes to go live.
#please-close


Added an option for expiration to user invitation

Hey, added an option for expiration to InviteNewUserService: IInviteNewUserService
Tests confirmed

Also, I noticed there is no check if the roles are valid for the user?
From what I have seen, a user can invite another user with app admin role?
If so, this needs to be addressed.. would happy to hear your thoughts

Hi @idan-h,

I noticed there is no check if the roles are valid for the user

That isn't correct. This section in the InviteNewUserService checks that invites to a tenant user have their roles checked.

Hi @idan-h,

I noticed there is no check if the roles are valid for the user

That isn't correct. This section in the InviteNewUserService checks that invites to a tenant user have their roles checked.

yea, I see it now.. Idk how I missed that. Removed the faulty commits.

Hi @idan-h,
I looked at your PR and it didn't link to the AddNewUserDto and didn't include any code to set the expiration. I therefore in version 3.4.0 I added the code to make it more part of the invite a user feature. I appreciated your suggestion and I thing the invite user feature is better for your input.

Hey, what do you mean by didn't see an expiration? I Added an option to add expiration time to the a new dto and added a check when adding the user.
You can see the test I wrote to understand better

If you want to add the check to the current dto for backwards compitability check it is fine by me, but I think that the expiration option is a must in this case (atleast for me).. I wouldn't want a user joining with a link after monthes

Hey, what do you mean by "didn't include any code to set the expiration"?

Sorry, you didn't create a frontend way to set the expiration  time. It wasn't that hard to do, but I always want the examples use all the features so that developers how it works. See example in Example3 and Example5.
I appreciate you help and suggestions but it is my decision whether I take a PR. Your idea was really good and the ReleaseNotes contains a (inspired by @idan-h) note against the expiration addition. The idea was yours and I just wrote the code in a way that was more part of the invite user code.

Hey, what do you mean by "didn't include any code to set the expiration"?

Sorry, you didn't create a frontend way to set the expiration  time. It wasn't that hard to do, but I always want the examples use all the features so that developers how it works. See example in Example3 and Example5.
I appreciate you help and suggestions but it is my decision whether I take a PR. Your idea was really good and the ReleaseNotes contains a (inspired by @idan-h) note against the expiration addition. The idea was yours and I just wrote the code in a way that was more part of the invite user code.

Oh, I do not care much about the credit and it wasn't my intention. Sorry if it came that way.
I thought you didn't recognize the need for this option so you didn't include it. My bad.
Anyway, I meant for the expiration to be set by the back-side only (as it is a security measure). But sure, some examples wouldn't hurt.


Generated output issue

Hi,
apologies if this is a basic issue, but I'm running the Colab notebook with a subscription.
I seem to be getting somewhere with the model training, but when it comes to output, there's issues.
Firstly the checkpoint path given under generate.py seems to be referencing a location that doesn't exist, with a 2020 date. If I change it to /logdir/default/27.12.2021_01.15.26/model.ckpt-10.index, which aligns with what I have, it does seem to try and export but the result is a tiny 108kb file named default_e=10_t=0.95.wav, rather than the set "test2.wav".
My training settings are as follows:
!python train.py
--data_dir ./chunks
--num_epochs 250
--batch_size 10
--max_checkpoints 2
--checkpoint_every 10
--output_file_dur 10
--sample_rate 11025
And my generate is:
!python generate.py
--output_path ./generated/default/test2.wav
--checkpoint_path ./logdir/default/27.12.2021_01.15.26/model.ckpt-10.index
--dur 10
--sample_rate 11025
--temperature 0.9
--config_file ./default.config.json
Any help would be really appreciated. Cheers!

Here's the result for hitting generate.py FWIW
2021-12-28 00:01:46.130675: W tensorflow/core/common_runtime/gpu/gpu_bfc_allocator.cc:39] Overriding allow_growth setting because the TF_FORCE_GPU_ALLOW_GROWTH environment variable is set. Original config value was 0.
Traceback (most recent call last):
File "generate.py", line 150, in
main()
File "generate.py", line 146, in main
args.sample_rate, args.temperature, args.seed, args.seed_offset)
File "generate.py", line 98, in generate
model = create_inference_model(ckpt_path, num_seqs, config)
File "generate.py", line 74, in create_inference_model
model.load_weights(ckpt_path).expect_partial()
File "/usr/local/lib/python3.7/dist-packages/keras/utils/traceback_utils.py", line 67, in error_handler
raise e.with_traceback(filtered_tb) from None
File "/usr/local/lib/python3.7/dist-packages/tensorflow/python/training/py_checkpoint_reader.py", line 35, in error_translator
raise errors_impl.NotFoundError(None, None, error_message)
tensorflow.python.framework.errors_impl.NotFoundError: Unsuccessful TensorSliceReader constructor: Failed to find any matching files for ./logdir/default/20.12.2020_06.15.46/model.ckpt-14

@CASE-WESTERN Hi, Perhaps the error arises because of this line:
--checkpoint_path ./logdir/default/27.12.2021_01.15.26/model.ckpt-10.index
Specifically the checkpoint name, model.ckpt-10.index - you have an extension, .index, and you don't need that... Individual checkpoints exist as multiple files on disk (an index file, which contains metadata, and one or more data files, which contain the values the different model variables), but they are always referenced without any extension.
It seems odd that it seems to be looking for a different checkpoint. But I hope that fixes it, let me know if not.

Removing the .index seems to be working!
Is checkpoint_path something that should be automatically updated with the most updated training model, or is the 20.12.2020 I see a placeholder that I need to manually update?
Unrelated, any reason why the training will cut out/"finish" every 5 epochs, even if num_epochs is currently at 250?
Thanks again!

Glad to be of some help. Perhaps this further issue is related to the --early_stopping_patience param. If the validation loss goes in the wrong direction for more than the number of epochs specified by this param (the default is 5) then the training will automatically stop. By wrong direction I mean if it rises whilst the training loss continues to descend. This indicates overfitting.
 Ideally you want >2000 audio chunks. A large chunk overlap can help increase the dataset size. I notice that your batch size is only 10, which is definitely too small. So your training might be overfitting, which means the early stopping will kick in. You can examine the progress of training by running TensorBoard. Navigate to the top level of the repository at the command line and run:
tensorboard --logdir=logdir/default --port=6006
It will open in your default browser on localhost:6006 (change the port to whatever you like).
If you don't specify an id for the training then it will use the default, which is default. Using an id creates a new folder with that name under logdir. For each 'run' using the same id a subfolder in that folder will be generated, named with a timestamp. You don't need to modify these. If --resume is True (which is the default) then the training will pick up from the last saved checkpoint (or you can specify a particular checkpoint). A new timestamped folder will still be created, however.

I've noticed the training tends to deviate from accuracy and then improve, but the highest I've seen so far is 0.65
My data set might be the issue. It's around 40 minutes in length, but with the sample size left to default I was only getting around 300 chunks to work with. I'll shrink the chunk size down to something more fitting and see how she makes out.
This is fascinating stuff and I can see how fine tuning will become very much an art.
Cheers!


use psycopg2-binary insted of  psycopg2==2.8.3

What type of PR is this?

[ ] Refactor
[ ] Feature
[ ] Bug Fix
[ ] New Query Runner (Data Source)
[ ] New Alert Destination
[ ] Other

Description

#72
use psycopg2-binary insted of psycopg2==2.8.3
How is this tested?

[ ] Unit tests (pytest, jest)
[ ] E2E Tests (Cypress)
[ ] Manually
[ ] N/A

Related Tickets & Documents

Mobile & Desktop Screenshots/Recordings (if there are UI changes)

@Avey777 I think I accidentally gave you bad advice the other day regarding merging of PRs'.
I said something like "Choose the 'Create a merge commit` option", unless there are multiple commits.
That's actually turning out to have a kind of messy result for our commit history.  The option that's turning out to work better is the "Rebase and merge" option.
That adds the commit for the PR directly to the commit history, without adding any of those useless Merge pull request #XYZ from somefork/somebranch commits.
So, please go with that option instead for PRs' with just a single commit. :smile:


Test Serialize & Deserialize

This request introduces a few new tests, some of which are failing (as per issue #45) - however the components failing were untested and IMHO fundamental to the functionality of the library. In Detail:

AttendeeTest is simply the EventTest class replicated for attendees. The remove test currently fails - i.e. if adding and then removing an attendee (with the remove method), the attendee is not removed.
SerializationTest has been renamed to DeserializationTest, as all these tests are reading a string to create an object model.
The utility methods to compare 2 calendars remains in SerializationTest
Several serialization tests are now added. All are failing, as currently very little is being serialized by the serialization engine, as per the description in issue #45. All tests are logging the serialized string, and if you look at the test output you will see why they are failing.

There are still weaknesses with the test - for example the testers computer must have the specified SystemTimeZone, but it is a start.

Thanks, @mcshaz - This (serialization, as opposed to deserialization) is definitely an area where the unit tests are very weak. I appreciate you taking the time to add them.

(Oh, in the future, you may want to use example.com as the test domain for things. That's its purpose: https://www.iana.org/domains/reserved )

Ah, you forgot to add them to the csproj file. I'll fix that momentarily.

Thanks for fixing and apologies.


Add cf start redis-example-app to start the app

Add cf start redis-example-app to start the app. CF tells you to restage after binding but
you can't do this becasue the app has yet to be staged.

Thanks Duncan.


Add rat king fan outfit

About the PR
Adds an outfit to the maintenance loot (clothing+fluff) spawner.
Outfit made by Hyenh on the Nyanotrasen Discord.
Media

WOOOOOOOO, PULL THIS PLEASE GOD

The humanoid in the top left is a female, isn't she? I can see one brown pixel of the shirt floating disconnected above the background. This would suggest the female mask is cutting off part of the sprite.

Limited edition run.


perf reduce waiting in task scheduler to accelerate consume (#33756)

pick (#33756)

run buildall

run buildall


Music desync when lagging

Geode Issue

[X] I confirm that this bug is NOT related to a mod but directly to Geode Loader itself.

Platform
Android64
SDK commit
No response
Geode Version
3.9.0
Mods Installed
Better edit, globed, better info, level thumbnails
Expected Behavior
Normal music sync, even when lagging.
Actual Behavior
Started playing sayitback on normal gd and nothing was wrong. Installed geode and tried playing l, but the moment the games lags Evel a little bit, the music desyncs from the level. Tried save mode, but it only reduced the lag slightly and didn't solve the problem. The issue persists in practice mode, but the music syncs up with the level upon death.
Steps to Reproduce
Start playing a demanding level, wait for the first lag spike, music gets desynced
Additional Information
Android 14 Xiaomi poco F5 8gb ram

That is Geometry Dash bug itself. (im not spam bot my acc is new cuz i lost old acc)


Different screenshot between { headless: false } and { headless: true } for page.setContent

When running puppeteer headless and using the setContent method, I observe a large difference in rendering for certain pages. Example attached for Dior landing page https://www.dior.com/home/fr_fr
Headless false:

Headless true:

Code in gist: https://gist.github.com/ledge74/6985e4914db3bd3e494576ccd7696bb4
Puppeteer version 0.10.2
tested on MacOS 10.12.6 and Ubuntu 16.04

If you add these lines right after browser.newPage(), it will work as expected:
await page.setUserAgent('Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36');
await page.setExtraHTTPHeaders({
  'accept-language': 'en-US,en;q=0.8'
});


Add rockspec and make test command

This diff adds the rockspec file.
This diff adds a local make test command, to locally tests the busted files.

Merging with broken CI, because License issues 😢


WIP: Add API methods for support staff

Coverage decreased (-0.8%) to 82.501% when pulling 048108172df6cd17ebe5ff9bc017c89fced77e1d on isocolsky:feat/support into c5d9f44b2dc1048cf2a78c57ec813154ac19e518 on bitpay:master.

Coverage decreased (-0.08%) to 83.218% when pulling 279d2ecc6848c4c62fe7c6f7c1ecbd58bfb70f98 on isocolsky:feat/support into c5d9f44b2dc1048cf2a78c57ec813154ac19e518 on bitpay:master.

Thank you for reviewing!


Update header formatting for README.md file

Small PR to fix the Markdown formatting in the REAME.md file since GitHub doesn't render inline HTML style attributes.

Codecov Report
Patch and project coverage have no change.

Comparison is base (53b7841) 96.91% compared to head (bf066d9) 96.91%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
Additional details and impacted files
@@           Coverage Diff           @@
##             main      #99   +/-   ##
=======================================
  Coverage   96.91%   96.91%
=======================================
  Files          25       25
  Lines         615      615
  Branches       80       80
=======================================
  Hits          596      596
  Misses         19       19

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Add a default secure ingress volume

its usage is described here https://vadimeisenbergibm.github.io/docs/tasks/traffic-management-v1alpha3/ingress.html#add-a-secure-port-https-to-our-gateway

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: costinm
Assign the PR to them by writing /assign @costinm in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

install/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@vadimeisenbergibm: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-unit-tests.sh
3c216c281d9c015d1b9f5be7a4fbc105e3182394
link
/test istio-unit-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@vadimeisenbergibm: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-unit-tests.sh
3c216c281d9c015d1b9f5be7a4fbc105e3182394
link
/test istio-unit-tests

prow/istio-pilot-e2e.sh
3c216c281d9c015d1b9f5be7a4fbc105e3182394
link
/test istio-pilot-e2e

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test istio-unit-tests

@vadimeisenbergibm: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-pilot-e2e.sh
3c216c281d9c015d1b9f5be7a4fbc105e3182394
link
/test istio-pilot-e2e

prow/istio-unit-tests.sh
3c216c281d9c015d1b9f5be7a4fbc105e3182394
link
/test istio-unit-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@vadimeisenbergibm: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-bookInfoTests.sh
ac8a2c57b6d99e2079473d71ae2b7c3adc533038
link
/test e2e-bookInfo

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test e2e-bookInfo


Upgrade nettle to version 3.6

Checklist

[ ] Used a fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.
I do have some suggestions for making it better though...
For recipe:

License is not an SPDX identifier (or a custom LicenseRef) nor an SPDX license expression.

Documentation on acceptable licenses can be found here.

@conda-forge-admin, please rerender

@conda-forge/nettle, this is ready.

@erykoff, would you like to become a maintainer for this feedstock? Looks like this feedstock is abandoned

Sure, why not.  (And I agree.)


500 when writing to a key that exists

Steps to reproduce (using httpie):
$ http <server> name=foo url=bar
HTTP/1.1 200 OK
Connection: keep-alive
Content-Type: application/json; charset=utf-8
Date: Wed, 14 Mar 2018 15:41:31 GMT
Server: nginx/1.12.1
Strict-Transport-Security: max-age=31536000; includeSubDomains
Transfer-Encoding: chunked

{
    "id": 23,
    "result": "success"
}

Follwed by:
$ http <server> name=foo url=bar
HTTP/1.1 500 Internal Server Error
Connection: keep-alive
Content-Type: text/plain; charset=utf-8
Date: Wed, 14 Mar 2018 15:43:30 GMT
Server: nginx/1.12.1
Strict-Transport-Security: max-age=31536000; includeSubDomains
Transfer-Encoding: chunked

Something went wrong

This is expected, though ugly, behavior. The database returns an error when you try to create a non-unique name.

Right. We should catch that database violation and return it as a 409 Conflict or something, with a better error message.

Working on this. I just need to figure out how to import an Exception/data constructor thingie.


Google Mediapipe HairSegmentation proto file missing

Hi,
I am using Android to compile Mediapipe's Hair segmentation App, but getting these two error
import com.google.mediapipe.proto.CalculatorProto.CalculatorGraphConfig;
import com.google.mediapipe.proto.GraphTemplateProto.CalculatorGraphTemplate;
As unable to find these files to import. Please Help!!
Thanks

resolved this issue by myself. you can email me to know how if you also face this issue.
<EMAIL_ADDRESS>Thanks!

Sorry for the late response. If you solved the problem, please post your solution. Thanks.
Back to your original question, what do you mention by using Android to compile hair segmentation app? Do you mean Android Studio? I tested the Bazel command and it works ok.
$ bazel build -c opt --config=android_arm64 mediapipe/examples/android/src/java/com/google/mediapipe/apps/hairsegmentationgpu
...
Target //mediapipe/examples/android/src/java/com/google/mediapipe/apps/hairsegmentationgpu:hairsegmentationgpu up-to-date:
  bazel-bin/mediapipe/examples/android/src/java/com/google/mediapipe/apps/hairsegmentationgpu/hairsegmentationgpu_deploy.jar
  bazel-bin/mediapipe/examples/android/src/java/com/google/mediapipe/apps/hairsegmentationgpu/hairsegmentationgpu_unsigned.apk
  bazel-bin/mediapipe/examples/android/src/java/com/google/mediapipe/apps/hairsegmentationgpu/hairsegmentationgpu.apk
INFO: Elapsed time: 147.466s, Critical Path: 116.92s
INFO: 1394 processes: 1276 linux-sandbox, 118 worker.
INFO: Build completed successfully, 1412 total actions

just need to add code to import external lib in app.gradle will remove this issue.
Thanks

Thanks for posting your solution!

just need to add code to import external lib in app.gradle will remove this issue.
Thanks

Can you provide the external lib plz?


Support @Inject for injected parameters

resolves #851

@rajinder-yadav Variable names are improved now.

:shipit:


LoRA Integration, and Model Configurations in SDP Codebase

Dear Author,
Thank you for sharing this fantastic work and for making the code publicly available. I have thoroughly enjoyed reading the paper and exploring the repository. I find your work on Sparse Diffusion Policy (SDP) truly inspiring, and I am deeply interested in learning more.
I have a few questions regarding the visualizations, LoRA integration, and the configurations of the models mentioned in your paper:

LoRA Integration:
I understand that your paper compares SDP with methods like FFT and LoRA. However, I am unsure how to adapt LoRA to your current code.

Would you be willing to provide guidance or experimental code for integrating LoRA into your framework for comparison?
This would help me better understand the interaction between different adaptation techniques in sparse policy learning.

SDP and Light SDP:
Your paper discusses two model configurations:

SDP: The full model, with relatively fewer experts, each having the same size as the original feed-forward network (FFN). Activated parameters are 53.3M.
Light SDP: A lightweight version, increasing the number of experts (e.g., from 8 to 16) while reducing the size of each expert (1/16 of the original FFN), resulting in activated parameters of 38.7M for efficiency in resource-constrained scenarios.
Are both SDP and Light SDP implementations included in the codebase? If so, could you indicate the specific locations or configurations to switch between the two?

Rou. only and Scratch Methods:
Your paper highlights the impressive efficiency of Rou. only, achieving superior task transfer with just 0.1M trainable parameters, compared to Scratch.

Could you kindly indicate where in the repository the implementations for Rou. only and Scratch are located?

Visualization:
The visualizations in the paper, such as expert sparsity, task transfer probabilities, expert selection frequency, and expert scores versus timesteps, are highly informative.

Could you kindly guide me on where in the codebase I should add or modify code to reproduce these visualizations?
Any pointers on specific files or functions where visualization hooks are implemented would be greatly appreciated.

I deeply value your time and assistance. My sole intention is to explore your excellent work further for academic interest and research purposes. Thank you for considering my request

Thanks for your interest, we plan to release code for rout. only and scratch methods probably in the last of this year or in the start of this year. For light SDP, you can modify the parameters in Task Moe class. For lora you can add lora adapter directly for transformer mlp. For visualization, you can compute in task moe, which experts is activated (or most prob) during policy testing.


Upgrade mkdocs

Upgrade mkdocs along with mkdocs-codeinclude-plugin, adopting new superfences tab title syntax.

Updated PR for 2021 and force-pushed to this branch 😅


Correction for raw affiliation CNRS, IHRIM (UMR 5317), ENS de Lyon

Correction needed for raw affiliation CNRS, IHRIM (UMR 5317), ENS de Lyon
raw_affiliation_name: CNRS, IHRIM (UMR 5317), ENS de Lyon
new_rors: 04zmssz18;02feahw73;02wmc6m46
previous_rors: 04zmssz18;02feahw73
works_examples: W2604243342
contact: 0693aec62a5829238f78382134f49972:c3e16525c1e88a2d1b56a85b1447 @ ens-lyon.fr

This issue was accepted and ingested by the OpenAlex team on 2024-11-01. The new affiliations should be visible within the next 7 days.


rcsb_attributes schema restructured to dict

The schema rcsb_attributes was restructured from using the SchemaGroup class to a dictionary.

Superseded by https://github.com/rcsb/py-rcsbsearchapi/pull/46


Multi-paged Drawing Canvas with Panning Enabled

First of all, victory dance 💃🏽 💃🏽 💃🏽 💃🏽 💃🏽 💃🏽 💃🏽
This PR includes support for a multiple-paged drawing canvas with panning enabled so users can scroll to find more areas to draw on. The current approach uses InteractiveViewer out of the box and specifies a default page count which produces an n × n grid of pages (where n is the default page count).
I admit it's not the best approach but it's a good start. A better approach would be to programmatically generate more space on scroll with good caching mechanism(s) to keep other parts that are just slightly outside the viewport handy in case of reuse.
Whenever that lands, it can benefit from some foundations laid in this PR.
New DrawingMode
A new drawing mode (DrawingMode.none) has been introduced to allow panning. When this is enabled from the CanvasSideBar, it disables pointer events from recording strokes and allows panning.
Indicative Cursor
Along with the new drawing mode, there's now support for indicative cursors. The cursor indicates that a drawing action can be performed when in other drawing modes apart from DrawingMode.none. And when in DrawingMode.none, the cursor is a basic pointer.
This can be extended to handle dragging in future releases.
Panning
Users can pan across multiple pages as long as there's at least one Sketch drawn. There's a helpful button to bring them back to the content area when they scroll away from their sketches to empty spaces. When the canvas is cleared, the InteractiveViewer is scrolled to its initial offset and panning disabled until another Sketch is drawn. The restriction of requiring at least one Sketch to be drawn before panning can be enabled is there to make the "Scroll back to content" logic (for when they scroll away from sketches) more accurate.
Background Image Update
With support for multiple pages coming to the canvas, the background image drawing logic has also been updated.  Images are resized along their widths to prevent distortions. In the future, there can be support for something like BoxFit to allow users determine how they'd like their images to fit.
Exporting Drawing
With the introduction of the multi-paged canvas, exporting requires an update. This is necessary because if the user only draws on one or two pages in the n × n grid, they should see an exported image that contains their drawings without unnecessary whitespace from unutilized pages.
The logic figures out the page extents to include in the exported image and it does this by:

comparing the furthest offset of a sketch from the origin (0,0)
temporarily resizing the canvas to the required dimensions
generating the image from RenderRepaintBoundary
and then restoring the size.

For this reason, the drawing canvas now has reactive height and width.
This also works well with background image included. We can now use the intuitive image drawing logic in SketchPainter to specify the exact amount of rows and columns that need to be painted with images.
Other Changes

UndoRedoStack has been moved up to DrawingPage so it can register a callback that is necessary for sanitizing pan state when the canvas is cleared from CanvasSideBar.
DrawingPage is now a StatefulHookWidget and some ValueNotifier objects moved up into the State to allow for listener callback registrations which are essential to the panning feature.
canvasGlobalKey is now owned by DrawingPage's State as well for performance reasons.
The canvas' dimensions are reactive to allow for the temporary resizing of the canvas during exports.
SketchPainter will repaint when backgroundImage changes.

@Crazelu great PR and great code but I feel like this new Multi-paged canvas feature is moving the project away from what I originally envisioned it. I basically just wanted the project to be a one-paged canvas that shows how you can achieve doodling and drawing shapes on the canvas.
The new arrows are pretty cool and that'll be a cool new PR if possible. Also, I added a 'features-to-explore' section to the readme. https://github.com/JideGuru/flutter_drawing_board#features-to-explore
Thanks for taking the time to contribute

@JideGuru thanks for your feedback. I really love the multi-paged canvas capability and I'll continue exploring that on a separate project.