Bug 92567 - Extra charracters at end of file.
Summary: Extra charracters at end of file.
Status: NEW
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Resources (show other bugs)
Version: 3.3   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Platform-Resources-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-04-25 08:16 EDT by Lars Soelgaard CLA
Modified: 2019-09-06 15:36 EDT (History)
2 users (show)

See Also:


Attachments
Fixed version of LocalFile.java (14.07 KB, text/plain)
2007-04-23 00:50 EDT, Campbell Moss CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Lars Soelgaard CLA 2005-04-25 08:16:15 EDT
When saving a source file there are extra characters saved at the end of the file.
This only happens if i have deleted lets say 10 characters. The last 10
characters of the file are repeated.

Ex:
  std::cout << "Hello World\n";

  std::cout << "Hello again\n";

}

Saving this works, but if i remove the blank lines and save the file it is saved as:

  std::cout << "Hello World\n";
  std::cout << "Hello again\n";
}
}

I'm using samba to access my projects on a file server.

If i create a local project on my desktop i can't create the same bug.
Comment 1 Campbell Moss CLA 2007-04-23 00:50:08 EDT
Created attachment 64563 [details]
Fixed version of LocalFile.java

This is a proposed fix for the issue described in this bug report. I would have attached a patch file, but the corporate firewall I'm behind prevents access to Eclipse's CVS repository.
Comment 2 Campbell Moss CLA 2007-04-23 01:06:26 EDT
I've also encountered this bug while saving files from Eclipse running under Windows XP to a Samba share on a SunOS box. I'm guessing that this issue stems from some peculiarity in the Samba setup here, or it would be much more widely reported. 
Anyway, what seems to be happening is that when a FileOutputStream is opened on an existing file on the Samba share, the file contents aren't cleared as they should be. Any bytes subsequently written to the stream will overwrite bytes in the existing file. If the file being saved is smaller than the file on disk, there won't be enough bytes to entirely overwrite the file on disk, so the end of the old file will remain. 
See the java file I've attached to this bug report for a proposed fix.
Comment 3 Anton Leherbauer CLA 2007-04-23 03:25:52 EDT
Seems to be a Platform issue. Changing Product/Component.
Comment 4 John Arthorne CLA 2007-04-23 09:45:08 EDT
Campbell: Your version of LocalFile seems to be based on an older version. When I compare against current HEAD I see many changes. What version of LocalFile did you start with? Can list the methods that you changed?
Comment 5 Campbell Moss CLA 2007-04-23 17:14:29 EDT
(In reply to comment #4)

Hi John,
Yes, sorry about that - as mentioned in the attachment comment, I'm currently unable to access CVS due to draconian corporate firewall rules. 
I started with the version of LocalFile that comes with Eclipse SDK 3.2.2 (i.e. org.eclipse.core.filesystem_1.0.0.v20060603).
I've changed the method openOutputStream(int, IProgressMonitor), and added safeClose(OutputStream).
Would it be better if I waited until I can get CVS access?
Comment 6 John Arthorne CLA 2007-04-23 17:25:33 EDT
No, I can figure it out now that I know what version it's based on.  I'm not sure this trick is going to work on all platforms and with all VMs - it will need some more testing.
Comment 7 Eclipse Webmaster CLA 2019-09-06 15:36:33 EDT
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.