lifearttw / macfuse

Automatically exported from code.google.com/p/macfuse
0 stars 0 forks source link

File size not reduced #80

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Connect to SFTP server
2. Edit a text file in BBEdit (I used 8.6 (174))
3. Incrementally save the file while reducing file content from middle
    -I was editing a source file and removed unneeded lines in the middle of the file.
    -I saved after each edit,
    -The bytes at the end of the file were not truncated as expected.

What is the expected output? What do you see instead?
I expected the file to be truncated to include only the text that was remaining 
in the editor.
Instead, it's like the space allocated for the file remained constant and each 
save merely over-
wrote the previous copy of the file.  This resulted in some partial comment 
blocks, unterminated 
function definitions, etc in my C source file.  I was running make and it kept 
failing. I opened the 
file on a remote box that has access to this file mounted via CIFS and the file 
contained all the 
expected contents, plus parts of each of the previous saves.

What version of the product are you using? On what operating system?
sshfs ver 0.1.0
MacFUSE ver 0.1.9
Mac OS X 10.4.8 PPC

Please provide any additional information below.

Original issue reported on code.google.com by de.c...@gmail.com on 1 Feb 2007 at 5:57

GoogleCodeExporter commented 8 years ago
When you say "connect to SFTP server", do you mean using the SFTP menu items in 
BBEdit itself? Are you 
connected to the SFTP server through BBEdit *and* you also have the remote 
server mounted through sshfs
+MacFUSE? Did you use the GUI wrapper (sshfs.app) to mount the remote server or 
did you use the command-
line program within the .app? If it's the latter, what's the exact command line 
that you used?

Original comment by si...@gmail.com on 1 Feb 2007 at 6:52

GoogleCodeExporter commented 8 years ago
By the way, you should know that MacFUSE (and the FUSE API) does not support 
the exchangedata() system call.

Original comment by si...@gmail.com on 2 Feb 2007 at 3:33

GoogleCodeExporter commented 8 years ago
I can verify this. I have been working with images - I replaced the image on the
server with a larger version on one machine and then, using macfuse, 
transferred the
newer, larger version over to my macbook. The result was that only 
sizeof(oldfile)
bytes had been copied to the macbook, so the image was corrupted. 

Original comment by simonwalton on 7 Feb 2007 at 5:55

GoogleCodeExporter commented 8 years ago
MacFUSE users need to understand that MacFUSE itself isn't a distributed remote 
file system! If you change 
things "externally" to MacFUSE (like, a file on the remote server in the case 
of sshfs), in general, things need to 
be done proactively to tell MacFUSE that something has changed, otherwise 
you'll get such "incorrect" 
behavior. For one, if you want this mode of operation (where you can change 
things remotely at any time) to 
work better, you should disable caching in sshfs (look at the various '-o 
cache' options, in particular, '-o 
cache=no').

Then, you need to tell MacFUSE not to cache things on its end too. In release 
0.1.9, you should use the '-
onoubc,noreadahead' options. This will not take care of everything though. In 
the upcoming release, there will 
be a new option that you should add to this: novncache. The combination of 
these 3 options should give you 
the desired behavior.

Original comment by si...@gmail.com on 7 Feb 2007 at 7:31

GoogleCodeExporter commented 8 years ago
Please try the following in MacFUSE 0.2.0 and see if you get the desired 
behavior:

sshfs user@host:/whatever/dir /whatever/mount/point -ocache=no -onolocalcaches 
-owhatever_other_options

Original comment by si...@gmail.com on 12 Feb 2007 at 7:08