Resolved / Sudden SFTP uploading troubles

I can see by the video you shared (privately) that the upload stops on a file called “data.archive”. RW does not generate this file, so this might be from a third-party theme or plugin.

It looks like “data.archive” is the troublesome file. I wonder why…

Do you have any idea what plugin/stack is generating that file? If we can figure that out we could perhaps work out how to remove the offending page/file and see if publishing works.

Can you send me over the RW project file? if you’re okay with that, send it to “dan at Realmac Software dot com” and I will try publishing it to a private area on our A2 server.

Thanks
Dan

1 Like

Mac OS 10.13.6,
RW8.7, Stacks4.1, Foundry2.3

There were no upload problems here until ≈RW8.6 and now RW8.7

Settings are FTP, Extended Passive mode (also tried other modes)

→ If only a few files are uploaded = ok

if the whole project is to be uploaded - the upload stalls midway.

So Transmit is helps in this case.

/
with best regards, Omar KN, Stockholm, Sweden

1 Like

I went thru all of this a few months ago…here is my last post on the subject…
I was hesitant to mention hosting company as they were involved trying to sort out the problem. They eventually referred me to a support person in Realmac who requested logs which I sent. Since then I have heard nothing from realmac, but mysteriously the issue has disappeared. I am grateful it appears to have gone away. But I would like answers to whether realmac imposes upload limits or speedlimiting on its RW customers because I would like to avoid these issues reappearing at a later date. If realmac DOES any of those things with the PUBLISH facility, I think they should be clearly stated somewhere for all to see, or clearly denied so that customers dont waste time and resources wondering. Perhaps that info is published somewhere and if it is I would be grateful for a link. If it happens again then I will certainly provide complete details on this forum.

Well, so far the problem hasnt returned. Teefers and another vouched for fact that RW did not throttle customers. Many different suggestions from many people blamed all the players…me, the host, RW, ftp,sftp, too many connections, ISP, Quite confusing. Just keep pursuing all the options/causes and hopefully a resolution will mysteriously appear like mine did altho you may never, like me, find out the actual cause. I was totally unable to upload full site for about a week.

Another possibility that could have been in play at that time, and has only just been identified today. We had severe storms here a few days ago which knocked out a few towers around here. Caused me to get my ISP to interact with the carrier. It was found that my router had been trying to connect with an non-line of sight tower, instead of the perfect line of sight tower. Caused interruptions to access as it connected then fell out. Hundreds of times. The carrier has now effected a software fix so that whenever they see my router it will be directed to the correct tower. So far this is working much better. HTH.

1 Like

David @gilk,

You ask the same question back in September on this post and the question was answered

But let’s put this question to rest.

NO RealMac doesn’t impose any upload limits

Why on earth would they care about how often you change your live site. It’s not their bandwidth being used. There are thousands of users using Rapidweaver every single day on tens of thousands of sites hosted on almost every hosting company, and no one is being throttled by Rapidweaver.

Did you have an intermittent connection when you were browsing the Internet? Did you try any simple speed tests? Issues with email? Any app (including Rapidweaver) that is going to communicate (FTP, SFTP, HTTP, HTTPS, etc, etc ) uses the same gateway to connect with the Internet. If you’re not having issues with all connections then it’s probably not the issue.

There’s nothing magical happening here. Something changed that made things start working. If you didn’t change something then more than likely the host did.

The FTP protocol is ancient in the world of technology. It predates the Internet by over a decade. It was designed for private networks transmitting small amounts of data. It has zero security built-in, even login credentials including password are sent in the clear transmitted unencrypted. It’s easily and often hacked and Since FTP is unencrypted, man-in-the-middle attacks can and have been used to inject malware into software downloaded using FTP.

SFTP uses a secure shell (SSH), the same shell system administrators use to manage their servers. It creates a secure ”tunnel” and uses a completely different new file transfer protocol. It’s better designed to handle the larger amounts of data that today’s websites use. It does a lot less handshaking between the server and the client so it tends to be much more reliable.

Now, that being said, it’s not going to solve every publishing issue. If a Rapidweaver project doesn’t publish to your hosting company I’d probably first attempt to publish to a local folder. If you can’t publish locally you’ll never be able to publish to a remote server.

If you can publish locally without errors then you can always try a standalone FTP app like Transmit or FileZilla. All modern FTP apps support SFTP, so don’t be fooled by their name. If you can get a Transmit or Filezilla to work then you have a workaround until you figure out what RapidWeaver is having issues with.

Unfortunately, the publishing log part of RW doesn’t seem to be working with the latest release of RW (DevMate issue), so debugging publishing issues are going to be handicapped until that gets fixed.

If you can’t publish locally then there’s something wrong with something on one of the pages.

1 Like

RESOLVED — Publishing problems with RapidWeaver using SFTP

Just an update to fellow Weavers on this issue of FTP/SFTP publishing that I and other Weavers have been experiencing lately.

I think I may have resolved this problem for now by clearing out my resources area in RW and deleting files that obviously did not belong in there. Somehow, I unknowingly put files in RW resources that were causing conflict with SFTP — and once I removed those unneeded files and tried republishing, everything went smoothly and I could finally republish again using SFTP on RW.

So, if you are still experiencing similar problems, one place you may want to look at is the resources area of RW. Deleting unneeded files in RW resources solved the publishing problem for me. I hope it works for you as well.

Thanks again to all, especially @teefers and @dan, who offered constructive advice here on the Forum on how to resolve this problem. Everyone’s feedback and input has been much appreciated.

2 Likes

@kishaman1 Thanks for the update. But it may not be clear to others what are some examples of files that did not belong in Resources. If you could provide some examples it might help others later down the line. And how/why did they get there in the firs place? Again, this might help some others. This seems to have been a very complicated issue to resolve: so it might be worth it for some others to check their resource area to see if they have similar “unwanted” or “unneeded” files there. Thanks for your persistence in resolving this issue!

2 Likes

I’ve been helping Brian @kishaman1 via private messages on his publishing issue. So let me clear up what the issue was in his case.

It had nothing to do with RapidWeaver resources other than that’s where he had placed a single corrupted file. The file was called ”archives.png” and the screenshot reassembled the RW project file icon.

RapidWeaver was able to successfully publish this file to a local folder, however, even the standalone FTP app Transmit couldn’t publish this file. Transmit and probably RW when trying to remotely publish identified this file as a directory(folder) and wouldn’t publish it.

Since RealMac hasn’t been able to fix the publishing log ”devmate” bug the only way to identify the garbage file was with a standalone FTP app.

Of course, Transmit was able to identify the problem file for us, and Transmit just skipped the bad file/folder and kept going.

@dan any update on the devmate issue? This issue would probably been identified and fixed in no time with a log file.

4 Likes

@teefers Thanks for this explanation! Wow, it probably wasn’t obvious at all that a PNG file was corrupted.

3 Likes

Any chance we could get a copy of the troublesome project and/or the corrupted PNG file. Would be nice to be able to build a check into RapidWeaver so we can solve this issue for future users. Send it over to dan at Realmac Software dot com.

Cheers,
Dan

@dan — Thanks for the follow-up. As you may remember, you and I were recently communicating both privately on this forum and by regular e-mail concerning that problematic RW project file of mine. The last e-mail I sent you, with the RW project file attached for your analysis, was a couple months ago on 13 December 2020. You never responded to my follow-ups, so I never did find out about your analysis of the project file. If you like, I can send you that project file again. In that case, please follow up my last e-mail message to you, and I will be glad to resend the project for your continued analysis.

@kishaman1 I think the problem was the project ever came through… What is your email address so I can look it up?

@dan — Thank you for your reply. I just sent you my e-mail address by forum mail, as I do not want to announce my private e-mail address to the world.

Just to reconfirm: I had sent you my RW project file for analysis on 11 December 2020 and then again two days later. I received no reply from you to either mail, so I assumed you were not interested in looking further into this case.

If you would like to reply to those December 2020 e-mails now, I will be glad to respond promptly.

Okay, I still can’t seem to find them, perhaps they never cam through for some reason. Please can you send the project through again to: dan@realmacsoftware.com

Or direct message me here with a download link.

Sorry for the trouble, I’m sure we’ll get to the bottom of this.

Many Thanks!
Dan

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.