Atom: "Uncaught Error: ESPIPE, invalid seek" when saving to FTP mounted with gvfs

[marlencrabapple]

Title pretty much sums it up. No problems saving to a regular file system. SSHFS is fine too. I'm on Ubuntu 14.04 x64. I've encountered this error in various .99, .100, and .101 builds from the master branch.

[underoot]

I have this problem too. Fedora 20 x86_64. atom v. 0.105.0-1975882

[kevinsawicki]

@marlencrabapple or @underoot Can you confirm this is still an issue on the latest Atom release, 0.124? The node version used was recently upgraded to 0.11.13 and I just want to confirm whether that may have fixed this, thanks.

[marlencrabapple]

Sill happening unfortunately.

[evrisbeetlejuice]

I have this problem too. I m using MANJARO 0.8.10 x86_64 with 3.14 kernel and atom v. 0.124.0.
Probably the only thing that keeps me from using atom full time

[evrisbeetlejuice]

Still happening in atom v. 0.141.

[burabure]

still a problem

[ghost]

Same problem here. Fedora 20 x86_64 Atom v0.146.0 (2014-11-12)

[phaux]

It also erases the file you're trying to save... When I realised I lost about 1500 lines of CSS styles my asscheeks clenched so hard they nearly created a black hole. Thankfully I still had the website opened in a browser so I copy-pasted the stylesheet back... Unfuckingbelievable.

[burabure]

this issue is annoying, but never ever work directly on a production environment. Either use git then deploy or have a current backup at the very least.

[phaux]

Of course I would use git if it was up to me, but unfortunately they don't use it at where I work.

[evrisbeetlejuice]

Just droping by to agree with phaux. Any idea as to what is causing this problem?

[benogle]

Can someone paste in a stack trace?

[evrisbeetlejuice]

There you go.
EDIT: atom 0.161

Error: ESPIPE, invalid seek
  at Error (native)
  at Object.fs.writeSync (fs.js:559:20)
  at Object.fs.writeFileSync (fs.js:1020:21)
  at Object.fsPlus.writeFileSync (/usr/share/atom/resources/app/node_modules/fs-plus/lib/fs-plus.js:228:17)
  at File.module.exports.File.writeFileSync (/usr/share/atom/resources/app/node_modules/pathwatcher/lib/file.js:227:19)
  at File.module.exports.File.writeFileWithPrivilegeEscalationSync (/usr/share/atom/resources/app/node_modules/pathwatcher/lib/file.js:297:21)
  at File.module.exports.File.write (/usr/share/atom/resources/app/node_modules/pathwatcher/lib/file.js:286:12)
  at TextBuffer.module.exports.TextBuffer.saveAs (/usr/share/atom/resources/app/node_modules/text-buffer/lib/text-buffer.js:966:17)
  at TextBuffer.module.exports.TextBuffer.save (/usr/share/atom/resources/app/node_modules/text-buffer/lib/text-buffer.js:954:19)
  at TextEditor.module.exports.TextEditor.save (/usr/share/atom/resources/app/src/text-editor.js:585:26)
  at Pane.module.exports.Pane.saveItem (/usr/share/atom/resources/app/src/pane.js:511:16)
  at Pane.module.exports.Pane.saveActiveItem (/usr/share/atom/resources/app/src/pane.js:501:19)
  at Workspace.module.exports.Workspace.saveActivePaneItemAndReportErrors (/usr/share/atom/resources/app/src/workspace.js:603:44)
  at Workspace.module.exports.Workspace.saveActivePaneItem (/usr/share/atom/resources/app/src/workspace.js:593:19)
  at atom-workspace.atom.commands.add.core:save (/usr/share/atom/resources/app/src/workspace-element.js:295:30)
  at CommandRegistry.module.exports.CommandRegistry.handleCommandEvent (/usr/share/atom/resources/app/src/command-registry.js:243:29)
  at /usr/share/atom/resources/app/src/command-registry.js:3:61
  at KeymapManager.module.exports.KeymapManager.dispatchCommandEvent (/usr/share/atom/resources/app/node_modules/atom-keymap/lib/keymap-manager.js:549:16)
  at KeymapManager.module.exports.KeymapManager.handleKeyboardEvent (/usr/share/atom/resources/app/node_modules/atom-keymap/lib/keymap-manager.js:391:22)
  at HTMLDocument.module.exports.WindowEventHandler.onKeydown (/usr/share/atom/resources/app/src/window-event-handler.js:167:20)

[benogle]

We might be able to use fs.writeSync here instead. See: https://github.com/joyent/node/issues/6877

[aspexi]

Atom 0.165.0
Ubuntu 14.04

Issue still exists.

Can you just make ANY workaround that would block editing files mounted via gvfs and NOT erase it?

Lost some data due to this issue. Atom is removed and forgotten till it's more stable. Hope soon.

Overall it's a great tool.

[kevin-brown]

Atom 0.166.0
Ubuntu 14.04

Error: ESPIPE, invalid seek
  at Error (native)
  at Object.fs.writeSync (fs.js:559:20)
  at Object.fs.writeFileSync (fs.js:1020:21)
  at Object.fsPlus.writeFileSync (/usr/local/share/atom/resources/app/node_modules/fs-plus/lib/fs-plus.js:228:17)
  at File.module.exports.File.writeFileSync (/usr/local/share/atom/resources/app/node_modules/pathwatcher/lib/file.js:227:19)
  at File.module.exports.File.writeFileWithPrivilegeEscalationSync (/usr/local/share/atom/resources/app/node_modules/pathwatcher/lib/file.js:297:21)
  at File.module.exports.File.write (/usr/local/share/atom/resources/app/node_modules/pathwatcher/lib/file.js:286:12)
  at TextBuffer.module.exports.TextBuffer.saveAs (/usr/local/share/atom/resources/app/node_modules/text-buffer/lib/text-buffer.js:966:17)
  at TextBuffer.module.exports.TextBuffer.save (/usr/local/share/atom/resources/app/node_modules/text-buffer/lib/text-buffer.js:954:19)
  at TextEditor.module.exports.TextEditor.save (/usr/local/share/atom/resources/app/src/text-editor.js:589:26)
  at Pane.module.exports.Pane.saveItem (/usr/local/share/atom/resources/app/src/pane.js:511:16)
  at Pane.module.exports.Pane.saveActiveItem (/usr/local/share/atom/resources/app/src/pane.js:501:19)
  at Workspace.module.exports.Workspace.saveActivePaneItemAndReportErrors (/usr/local/share/atom/resources/app/src/workspace.js:611:44)
  at Workspace.module.exports.Workspace.saveActivePaneItem (/usr/local/share/atom/resources/app/src/workspace.js:601:19)
  at atom-workspace.atom.commands.add.core:save (/usr/local/share/atom/resources/app/src/workspace-element.js:295:30)
  at CommandRegistry.module.exports.CommandRegistry.handleCommandEvent (/usr/local/share/atom/resources/app/src/command-registry.js:243:29)
  at /usr/local/share/atom/resources/app/src/command-registry.js:3:61
  at KeymapManager.module.exports.KeymapManager.dispatchCommandEvent (/usr/local/share/atom/resources/app/node_modules/atom-keymap/lib/keymap-manager.js:549:16)
  at KeymapManager.module.exports.KeymapManager.handleKeyboardEvent (/usr/local/share/atom/resources/app/node_modules/atom-keymap/lib/keymap-manager.js:391:22)
  at HTMLDocument.module.exports.WindowEventHandler.onKeydown (/usr/local/share/atom/resources/app/src/window-event-handler.js:167:20)

I'm interested in fixing this, though I have no idea where to start.

[benogle]

@kevin-brown try my suggestion in https://github.com/atom/atom/issues/2539#issuecomment-67533259 and related information at joyent/node#6877

[p-boiko]

Same here with version 0.210.0
Is it possible at least prevent file from emptying? Its annoying to have different editors for different purposes...

[mvincentmiller]

I'm using Ubuntu 14, and 'Add Project Folder' (a remote session folder). This will be awesome when it's fixed. Is anyone working on it? I'm guessing fs doesn't want to assume access to remote. My view from here: it could be an issue with Node/fs itself or there could be an easier solution.

---

Error: ESPIPE: invalid seek, write
at Error (native)
at Object.fs.writeSync (fs.js:657:20)
at Object.fs.writeFileSync (fs.js:1164:21)
at Object.fsPlus.writeFileSync (/usr/share/atom/resources/app.asar/node_modules/fs-plus/lib/fs-plus.js:279:17)
at File.module.exports.File.writeFileSync (/usr/share/atom/resources/app.asar/node_modules/pathwatcher/lib/file.js:264:19)
at File.module.exports.File.writeFileWithPrivilegeEscalationSync (/usr/share/atom/resources/app.asar/node_modules/pathwatcher/lib/file.js:362:21)
at File.module.exports.File.writeSync (/usr/share/atom/resources/app.asar/node_modules/pathwatcher/lib/file.js:336:12)
at TextBuffer.module.exports.TextBuffer.saveAs (/usr/share/atom/resources/app.asar/node_modules/text-buffer/lib/text-buffer.js:1028:17)
at TextBuffer.module.exports.TextBuffer.save (/usr/share/atom/resources/app.asar/node_modules/text-buffer/lib/text-buffer.js:1014:19)
at TextEditor.module.exports.TextEditor.save (/usr/share/atom/resources/app.asar/src/text-editor.js:578:26)

[christopherstokes]

This is still happening with the 1.0 release. I received the same error as @mvincentmiller. The file was completely blanked.

[mvincentmiller]

I can also confirm saving does empty the file (to 0k) when attempting to save to my remote server. Feels like a last-ditch security measure.

[IngvarLosev]

When will fix this bug?

[evrisbeetlejuice]

The day this will be fixed will be a happy day. Is there anything we can do to help? Is pasting another stack trace going to help?

If it wasn't for that bug Atom would be my main editor

[mvincentmiller]

I'm going to take a look at trying to patch this based on https://github.com/joyent/node/issues/6877. If this is already being done, or if I should wait for any other reason, would someone please alert me? I'll put in a formal request if I make any progress.

[tombimbom]

After a bit of a search I found out Atom to be the best choice for linux. Now the first try and such a big bug. Don't understand how so little people actually find this a problem. But the worst thing is that it's been more then a year now since this issue is reported and no fix yet..

Got to switch to something else :/

Ubuntu 14.04.2
Atom 1.0.0

[underoot]

@tombimbom For the last time I use in projects SFTP through SSH. Atom work with such type of mounted directory. And, Yes. I agree with your opinion, except switching to other editor!

[mvincentmiller]

No need to switch editors! Here's a work around: https://atom.io/packages/remote-ftp

[christopherstokes]

@underoot The issue was consistent with multiple users so whether or not it works for you doesn't exactly fix their issues.

@mvincentmiller This is what I'm talking about. I'll have to try this sometime when I'm not at work since losing data at work is kind of a big deal.

[p-boiko]

In the version 1.0.7 (may be some earlier too, didn't check it) Atom at least doesn't empty the file :)
The step in right direction! And another type of error appears:

Unable to save file: Invalid seek '/run/user/1000/gvfs/ftp:host=ftp.example-server.com/path-to-file

[DaVince]

@p-boiko: for me it shows me the error, then empties the file...

[p-boiko]

same here still. I'm not sure why in that case the file was left untouched. May be read only? Anyway, I confirm that the bug still persist

[zakjan]

Atom 1.2 on Fedora 23, the bug still exists. FTP file is not saved, it is erased instead.

[protman]

Ubuntu 15.04 "Invalid seek" and the file gets nuked. No problemo in SublimeText.

Also, my other mount using SFTP has no invalid seek errors when saving. The problematic one is using FTP and is reported as "Microsoft FTP"

I think this issue may only pertain to gvfs mounted FTP, not SFTP.

[camlafit]

Hi

I confirm this problem, on debian/jessie with gvfs mounted directories. Save on :

• Samba mount is ok
• SFTP mount is ok
• FTP mount is nok

Last Atom deb version used ; with gedit no problem on save files

Thanks a lot

[entr]

Still no working in 1.3.1

[hex0gen]

1.3.2 not fixed yet. Ubuntu 14.04x64.

[p-boiko]

since the same behavior and error messages shown are demonstrated by other node-based editors tested, I suspect the node`s IO subsystem

[p-boiko]

v1.4.1 update for those still interesting: I created new file with content and was able to save it on a remote ftp mounted as FUSE/GVFS successfully. But when I tried to save further editions I caught the error and a file became empty. Didn't check with other versions

I think it should be pretty easy for those familiar with Atom's internals to compare initial file saving and modified one's procedures to fix the bug

[erdkse]

Atom 1.6.0 , sftp mounted via gvfs is ok but ftp gets this error and file gets empty.

[p-boiko]

Tested again in 1.8.0-beta3
Create new file and save it on a gvfs-mounted ftp volume: SUCCESS! :)
Now make some changes and hit Save: Invalid seek and empty file....

Seems like to solve this issue is not big deal, but this thread somehow avoids the person who can do that. I'll keep posting here until resolved. This really affects my workflow...

[andreaolivieri87]

I have this problem too....
It's a Basic function broken...

I'm so sad... I was very happy using Atom...
At this point (after more then one year) i think this problem will not be solved soon

Ubuntu's best Alternative? Brackets?

[andreaolivieri87]

Brackets works fine!
It's possible to save via FTP

[p-boiko]

Update for Atom 1.8.0-beta4

Create new file → Save to a GVFS mounted FTP-volume → success
Make some modifications → save → fail: Invalid Seek Error, file empty...

Andrea,
Brackets fails for me with 'Unknown Error'

[p-boiko]

seems like the issue is connected to this: https://github.com/nodejs/node-v0.x-archive/issues/6877
And it seems to be an easy task for those familiar with Node's files IO system

[mvincentmiller]

Thanks for that link.

[franciscop]

Same issue here, I am working while porting the codebase and unfortunately I have to keep using FTP for hot-fixes. Atom deletes the folder. Works fine on gedit and I'm going to test Brackets now, but I love Atom and would like to keep using it.

[p-boiko]

So, 1.9.0-beta1 is officially rolled out and its time to save to one of my multiple fuse ftps volumes for testing purpose. The standard procedure:
· new file created, some random content typed in, save to an ftp – SUCCESS
· adding more content, saving – ERROR (invalid seek, file is empty).
Well, I'm patient.

[friimaind]

Same here with Ubuntu 16.04 Xenial + Atom 1.9.0-beta0:

• mount a new FTP source from Nautilus
• from Atom: Right click > create a new file => Success
• insert some content and hit Save => Fail

The error is:

Unable to save file: Invalid seek '/run/user/1000/gvfs/ftp:host=exampleftp.com,user=userftp/public_html/test.php'

EDIT. if it is useful: Sublime Text completes the same task on the same ftp's source.

[andreaolivieri87]

Yeah, the problem is clear.... but in the meantime how do you do save on ftp?
Which solution you found to continue to work without atom?

[friimaind]

@andreaolivieri87 Unfortunately I can't use Atom for this reason. I'm using Sublime Text which works as expected.

[franciscop]

@andreaolivier87 I am using Brackets for FTP, Atom for the rest

[franciscop]

It's almost like Github isn't really interested in fixing an FTP issue and prefer us to use git :grin:

[camlafit]

Here as I use git, I combine with git ftp to continue to use atom :)
But it's a bit ugly

[andreaolivieri87]

@friimaind lol i think NO ONE can use atom for the same reason...
Atom is just a really as beautiful as useless experiment

[mvincentmiller]

Ok folks let's start narrowing this down, though. Forget about Brackets and Sublime Text. The issue is definitely related to nodejs/node-v0.x-archive#6877. I emailed @trevnorris who seems to know the pattern well. This shouldn't be super tough.

[trevnorris]

Inject this into the top of your application and attempt to reproduce the error:

'use strict';

const TTYWrap = process.binding('tty_wrap');
const fs = require('fs');
const print = process._rawDebug;

const _writeSync = fs.writeSync;

fs.writeSync = function writeSync(fd) {
  print(`fd: ${fd} type: ${TTYWrap.guessHandleType(fd)}`);
  print(Array.from(arguments));
  return _writeSync.apply(this, arguments);
};

[mvincentmiller]

Something about position being undefined or 0 when passing position to fs.writeSync() indeed. I'm digging into errno.h to better understand the ESPIPE error and the proper way to write to pipes.

[(https://github.com/nodejs/node-v0.x-archive/blob/master/deps/uv/include/uv.h)]

[trevnorris]

Here's what's likely happening. When offset is undefined then it's changed to -1.
source: https://github.com/nodejs/node/blob/v4.4.5/src/node_file.cc#L1001
macro: https://github.com/nodejs/node/blob/v4.4.5/src/node_file.cc#L49

But if 0 is passed, then the offset is set to 0. The difference between these two is important because libuv will use read(2) if offset < 0 and pread(2) otherwise (ref: https://github.com/libuv/libuv/blob/v1.9.1/src/unix/fs.c#L281-L290). The important part is that pread(2) automatically performs a seek(2) operation. Which cannot be done on a socket or similar. So writing to FTP will fail.

Solution is to either fix electron to use the appropriate API based on the fd type, and not abuse the fact that fs can be used to write to any fs type if the arguments are correct, or at the minimum make it consistent across the code base so that it always passes undefined, or at least -1 in those cases.

[kirylpl]

Still same bag exist.
Is it really 21th century editor with no saving option?

[p-boiko]

@trevnorris, seems like you are close to solve the issue. Are there any chances that you'll fix the code and then add→commit→push soon?

[trevnorris]

@p-boiko The issue is with atom, which I've never actually contributed to. Was just pointing out my observations from the information that was given. A potential solution would be for atom to make sure offset is undefined instead of zero. That way it doesn't trigger a seek on the network drive. Though it's unlikely that that would solve the whole issue.

[mvincentmiller]

I'm looking at this as a hackathon of sorts. I have just barely enough of a general understanding down the stack to fix it. Is any one else interested in sorting this out? @trevnorris thanks for responding.

[mvincentmiller]

I'm also looking at this as a way to contribute. I don't know if anyone noticed that the stack trace has been removed from the error message. I didn't find a discussion, so I started one:

https://discuss.atom.io/t/invalid-seek-espipe-error-on-saving-to-remote/30144

This issue does have all sorts of labels, so obviously it isn't being ignored, folks. Might help to keep complaints to a minimum.

[50Wliu]

@mvincentmiller Here's a stack trace, though the line numbers most likely don't match up anymore...https://github.com/atom/atom/issues/2539#issuecomment-113933711. Thanks for looking into this!

edit: found a newer one

[p-boiko]

Sorry for the off topic, but in two weeks we have only 1 commit, fixing css (setting min-width to '0'). And there are plenty of unchecked pull requests. Does Atom's development stalled somehow? Are guys at github downshifted the Atom's priority?

[mvincentmiller]

@p-boiko let's figure that out, and I'm definitely moving forward to contribute to Atom.

[mvincentmiller]

@benogle might have some insights on the status of pull requests or Atom's development in general. @p-boiko Regardless of pulls / merges a person could still compile the editor locally, no? That would be my plan before submitting a pull.

[50Wliu]

Hey, unofficial Atom community volunteer here.
@p-boiko I believe you're looking at the wrong branch (1.9-releases by the sounds of it). You'll want to look at master instead for the day-to-day development. Pulse (https://github.com/atom/atom/pulse) gives me 11 merged PRs and 18 commits to master (33 to all branches) within the past week, so development definitely has not stalled.

@mvincentmiller @benogle no longer works on Atom.

[lee-dohm]

Does Atom's development stalled somehow? Are guys at github downshifted the Atom's priority?

@p-boiko We have a team of people working full-time at GitHub on Atom. I'm one of those people. No, there has been no downward change in Atom's priority for GitHub.

[trevnorris]

Demonstration of what's most likely going on:

const buf = Buffer('abc\n');
require('fs').writeSync(1, buf, 0, buf.length);

The above prints abc to stdout then exits. Now the following:

const buf = Buffer('abc\n');
require('fs').writeSync(1, buf, 0, buf.length, 0);

This fails with:

fs.js:658
    return binding.writeBuffer(fd, buffer, offset, length, position);
                   ^
Error: ESPIPE: invalid seek, write
    at Error (native)
    at Object.fs.writeSync (fs.js:658:20)

Looks familiar. Only difference is the position of 0 was passed, and that told libuv to use pwrite(2) instead of write(2).

Thanks to the stack trace we see that the call is made from fs.writeFileSync(). Let's take a quick look at the code from that function:

  var offset = 0;
  var length = data.length;
  var position = /a/.test(flag) ? null : 0;  // <--- Is set if 'a' is passed
  try {
    while (length > 0) {
      var written = fs.writeSync(fd, data, offset, length, position);
      offset += written;
      length -= written;
      if (position !== null) {
        position += written;
      }
    }
  } finally {
    fs.closeSync(fd);
  }

The only way for position to not be null is if the append flag was passed when the file was opened. Causing libuv to use pwrite(2), which automatically does a seek on the fd causing the failure. Because writeFileSync() is writing the entire file it doesn't allow a position argument to be passed. Excluding that possibility. So the first thing I would do would be to log options.mode in a similar manner as I did in https://github.com/atom/atom/issues/2539#issuecomment-224420097.

Though one problem is there's no option to pass the append flag from File#writeFileSync() in node_modules/pathwatcher/lib/file.js. So I may be completely off. If you post the arguments passed to the function when it throws I'll be able to tell you what's going on.

[mvincentmiller]

I peaked at the source (Coffeescript... hrmph) and I'm proceeding to build locally... Thanks @trevnorris! [edit: matched the stack trace to above advice]

[p-boiko]

Sorry, didn't mean to offend anybody by my comment. Yes, @50Wliu , I looked here http://screencloud.net/v/619J
Thank you all guys (and girls?) for your efforts. I hope to contribute in future also. I love atom.

[ellocofray]

Linux Mint 17.3
Atom 1.7.4 same error.

[KrzysiuJarzyna]

Atom 1.8.0 and Ubuntu 16.04 and same error: "Unable to save file: Invalid seek..."

Really annoying. I can save remote files even by default text editor but not thru Atom.

[JoeHonk]

I found a temporary solution to this problem using curlftps. It allows for mounting ftp just like gvfs in Nautilus, but doesn't suffer from the blanking issues discussed in this thread.

• http://manpages.ubuntu.com/manpages/trusty/man1/curlftpfs.1.html
• https://github.com/claudiodangelis/gcurlftpfs

Most of the tutorials that can be found encourage the user to configure the connections so they auto-mount permanently in fstab, but that's probably unnecessary for most users. The python based gui works nicely, and only persists for the current user session.

[p-boiko]

Still there in the latest 1.10.0-beta0

[p-boiko]

Confirmation for 1.10.0-beta1:
"Save as" on a remote fs: success! Modifications and save file: "invalid seek" and file is empty :)

[mastercake10]

Error still exist:
Ubuntu 14.04.4 LTS

Unable to save file: Invalid seek

sftp works fine though ftp still fails.

[p-boiko]

1.10.0-beta5: the bug is still there

[p-boiko]

1.11.0-beta0 installed today with huge improvements list (mainly for MacOS users). No mention about the FUSE issue, but have to check it myself: "save" fails, "save as" succeeds...
Well, I'm patient :)

[hex0gen]

https://github.com/mgrenier/remote-ftp. I use this plugin since beginning of summer and now my hair smooth and silky.

[friimaind]

Tested 1.11.0-beta5, unfortunately the bug is still here :(

[p-boiko]

1.12.0-beta0 the issue is still there

[mvincentmiller]

@p-boiko just so you know I do see these in my email. Compiling Atom ended up being more of a process than I had thought, but the problem is fairly straightforward if we can find someone who already has the toolchain (coffeescript) set up and knows Fs, libenv and libuv. I've been tied up with life and learning TypeScript :/

[n33l33m3lj]

Workaround: Use SSH instead of FTP.

[p-boiko]

The bug is the first thing to test, when a new beta is rolled out :)
1.14.0-beta0... fails :(
remote-ftp is still in charge

[e-ht]

This bug is still active and will delete the contents of the page on server when you attempt to save. Yikes.

@n33l33m3lj not always possible working with clients' existing infrastructure.

[mvincentmiller]

Trevor Norris has hinted at the solution in previous comments.

[trevnorris]

To reiterate what the fix should be, instead of passing 0 to the position it should instead be undefined.

Though, writing to a file over FTP means it can only be appended to for each subsequent write. So the same file will need to be opened every time in order for it to be written to at position === 0, and there will be a problem trying to keep a fd open and writing to it at a new position. Instead the file will have to be opened and closed every time. Essentially it should just be using fs.writeFile[Sync]().

[mateusfccp]

Still happening on Arch Linux, Atom 1.15.0 x64.

[Drakota]

So any ETA on when this is gonna be fixed?

[50Wliu]

No ETA. We are aware of the issue however.

[cawa-93]

The problem is urgent for a node v7.7.4 - https://github.com/Microsoft/vscode/issues/6854#issuecomment-289087944

[arashkiani]

ubuntu 16.04 & atom 1.15.0 x64 ; im using my current setup on 5 servers 4 of which are fine via sftp, I can code in them and push things as if they were local.

Today for the first time I had to update a legacy project and when i saved; the file became empty! so i think the issue is more about server / connection protocal (ftp vs sftp).

its crazy how the bug was first reported in 2014 and is not solved yet

[p-boiko]

Checked with latest v1.19.0-beta0 - the bug is fixed for me :)

[matejmosko]

Heureka! v1.19.0-beta0 works for me.

[50Wliu]

Awesome news! I'm going to optimistically close this issue. It would be great if people who were experiencing this issue could download the beta (available at https://atom.io/beta) and report back with their findings. Thanks!

[mvincentmiller]

Sweet

[mastercake10]

nice work!

[entr]

Can someone reference the commit that fixes that please? Thanks!

On Wed, Jun 21, 2017, 8:31 PM Linus [e-mail] wrote:

nice work!

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/atom/atom/issues/2539#issuecomment-310149764, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AALsUzYyW74I7a2QKEb7-xGxrnGW7gL3ks5sGVNUgaJpZM4CCAJQ
.

[50Wliu]

@entr based on a conversation in Slack, it appears that moving away from the Node fs APIs and using C++'s fopen and friends instead fixed this issue. That work happened mostly in atom/superstring#5.

[RafaelLinux]

Well, the beta is beta, and now I have issues with some previously working packages ....

"Pigments" --------------------

1. Just open a php file

Atom: 1.19.0-beta5 x64
Electron: 1.6.9
OS: "openSUSE Tumbleweed"
Thrown From: pigments package 0.39.1

Stack Trace

Failed to activate the pigments package

At Cannot find 'highlights-component' in the require cache.

Error: Cannot find 'highlights-component' in the require cache.
    at requireCore (/packages/pigments/lib/pigments.coffee:310:19)
    at Object.patchAtom (/packages/pigments/lib/pigments.coffee:312:26)
    at Object.activate (/packages/pigments/lib/pigments.coffee:16:6)
    at Package.module.exports.Package.activateNow (/usr/share/atom-beta/resources/app/src/package.js:253:25)
    at /usr/share/atom-beta/resources/app/src/package.js:225:38
    at Package.module.exports.Package.measure (/usr/share/atom-beta/resources/app/src/package.js:99:21)
    at /usr/share/atom-beta/resources/app/src/package.js:218:32
    at Package.module.exports.Package.activate (/usr/share/atom-beta/resources/app/src/package.js:215:40)
    at PackageManager.module.exports.PackageManager.activatePackage (/usr/share/atom-beta/resources/app/src/package-manager.js:645:40)
    at /usr/share/atom-beta/resources/app/src/package-manager.js:626:35
    at Config.module.exports.Config.transactAsync (/usr/share/atom-beta/resources/app/src/config.js:346:24)
    at PackageManager.module.exports.PackageManager.activatePackages (/usr/share/atom-beta/resources/app/src/package-manager.js:621:25)
    at PackageManager.module.exports.PackageManager.activate (/usr/share/atom-beta/resources/app/src/package-manager.js:603:52)
    at /usr/share/atom-beta/resources/app/src/atom-environment.js:843:36

Commands

     -0:51 tree-view:show (atom-workspace.workspace.scrollbars-visible-always)

Non-Core Packages

activate-power-mode 2.0.0 
atom-autocomplete-php 0.25.6 
atom-beautify 0.30.4 
atom-clock 0.1.13 
atom-css-comb 3.3.0 
autocomplete-html-entities 0.1.0 
autocomplete-modules 1.6.10 
autoprefixer 3.7.1 
busy-signal 1.4.3 
color-picker 2.2.5 
emmet 2.4.3 
file-icons 2.1.9 
fonts 3.0.2 
hey-pane 1.0.0 
intentions 1.1.2 
linter 2.2.0 
linter-doiuse 0.2.3 
linter-htmlhint 1.3.3 
linter-jshint 3.1.5 
linter-php 1.3.2 
linter-ui-default 1.6.3 
minimap 4.29.2 
minimap-pigments 0.2.2 
open-recent 5.0.0 
pigments 0.39.1 
power-effects 0.3.0 
remember-file-positions 0.2.3 
remember-folds 0.3.0 
remote-edit2 3.0.0 
w3c-validation 0.4.0 

"activate-power-media" -------------------------------------------------------------
[Enter steps to reproduce:]

1. Just open a php file

Atom: 1.19.0-beta5 x64
Electron: 1.6.9
OS: "openSUSE Tumbleweed"
Thrown From: activate-power-mode package 2.0.0

Stack Trace

Uncaught TypeError: Cannot read property 'appendChild' of null

At /home/PALACIO/1400/.atom/packages/activate-power-mode/lib/canvas-renderer.coffee:52

TypeError: Cannot read property 'appendChild' of null
    at Object.setupCanvas (/packages/activate-power-mode/lib/canvas-renderer.coffee:52:20)
    at Object.onChangePane (/packages/activate-power-mode/lib/plugin/power-canvas.coffee:15:13)
    at /packages/activate-power-mode/lib/plugin-manager.coffee:88:32
    at Object.onEnabled (/packages/activate-power-mode/lib/plugin-registry.coffee:64:19)
    at Object.runOnChangePane (/packages/activate-power-mode/lib/plugin-manager.coffee:87:21)
    at Object.setupPane (/packages/activate-power-mode/lib/power-editor.coffee:40:20)
    at Object.enable (/packages/activate-power-mode/lib/power-editor.coffee:11:6)
    at Object.enable (/packages/activate-power-mode/lib/activate-power-mode.coffee:43:18)
    at Object.toggle (/packages/activate-power-mode/lib/activate-power-mode.coffee:39:38)
    at /packages/activate-power-mode/lib/activate-power-mode.coffee:28:10

Commands

     -1:00.6.0 tree-view:show (atom-workspace.workspace.scrollbars-visible-always)

Non-Core Packages

activate-power-mode 2.0.0 
atom-autocomplete-php 0.25.6 
atom-beautify 0.30.4 
atom-clock 0.1.13 
atom-css-comb 3.3.0 
autocomplete-html-entities 0.1.0 
autocomplete-modules 1.6.10 
autoprefixer 3.7.1 
busy-signal 1.4.3 
color-picker 2.2.5 
emmet 2.4.3 
file-icons 2.1.9 
fonts 3.0.2 
hey-pane 1.0.0 
intentions 1.1.2 
linter 2.2.0 
linter-doiuse 0.2.3 
linter-htmlhint 1.3.3 
linter-jshint 3.1.5 
linter-php 1.3.2 
linter-ui-default 1.6.3 
minimap 4.29.2 
minimap-pigments 0.2.2 
open-recent 5.0.0 
pigments 0.39.1 
power-effects 0.3.0 
remember-file-positions 0.2.3 
remember-folds 0.3.0 
remote-edit2 3.0.0 
w3c-validation 0.4.0 

[mvincentmiller]

Those issues are separate from this one though, right?

[RafaelLinux]

Yes, despite they are a consequence of "fixing" this one with a temporal solution.

[lee-dohm]

@RafaelLinux Please report those two exceptions to the packages that they are caused by. If the package authors find that there is a problem with the API changes, they are best equipped to work with us on how they could be fixed.

[p-boiko]

Hi guys.
For some long time already we are able to save on GVFS mounted volumes.
But I'm unable to search in files on the GVFS mounted folders due to the same error. It's a "Find in project Ctrl + Shift + F". Was unable to find a bug among open issues, but may be somebody is aware of workaround before I file a new issue. It's ridiculous to use a different editor for the sole operation :smile:

http://i.imgur.com/kWqfd9C.png

Thanks.

[lock[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. If you can still reproduce this issue in Safe Mode then please open a new issue and fill out the entire issue template to ensure that we have enough information to address your issue. Thanks!