GoogleCodeExporter
commented
9 years ago BTW, why do you think this issue is different from the earlier issue #155 that
you reported?Original comment by si...@gmail.com on 27 Apr 2007 at 9:26
Closed GoogleCodeExporter closed 9 years ago
GoogleCodeExporter
commented
9 years ago BTW, why do you think this issue is different from the earlier issue #155 that
you reported?Original comment by si...@gmail.com on 27 Apr 2007 at 9:26
GoogleCodeExporter
commented
9 years ago Yes, possibly the same ...
Under #155 we considered at the uid option.
Where previously
drwxrwxrwx 1 32952 wheel 0 Feb 7 2006 ndrive
I wasn't the owner, I assumed that this should be corrected
(and so Michael Gorbach is condering a GUI to expose some advanced options).
Having addressed that issue, that I _do_ still see error -43 in Finder, but I
_don't_ know whether -43 is
happening for the same reason. (Under #155 I didn't debug at command line.)
(In retrospect, *is* the uid an issue if directory privileges are drwxrwxrwx? I
wonder.)Original comment by grahampe...@gmail.com on 27 Apr 2007 at 9:40
GoogleCodeExporter
commented
9 years ago It is the same issue.
Try adding the '-onovncache' option to see if the behavior is any different.Original comment by si...@gmail.com on 27 Apr 2007 at 9:45
GoogleCodeExporter
commented
9 years ago grahamperrin:~/Volumes gjp22$ ls -lR
total 0
drwx------ 2 gjp22 staff 68 Apr 27 17:57 ndrive
./ndrive:
grahamperrin:~/Volumes gjp22$ sshfs
gjp22@ndrive.uscs.susx.ac.uk:/IBIS/HOME1/gjp22 ~/Volumes/ndrive
-onovncache,volname=ndrive
sshfs: cannot find sshnodelay.so
warning: ssh nodelay workaround disabled
gjp22@ndrive.uscs.susx.ac.uk's password:
grahamperrin:~/Volumes gjp22$ ls -al ndrive/
total 16
drwxrwxrwx 1 38091 wheel 0 Apr 27 20:47 .
-rwxrwxrwx 1 38091 wheel 6148 Apr 27 21:35 .DS_Store
drwxrwxrwx 1 32952 wheel 0 Dec 9 2005 Favorites
drwxrwxrwx 1 38091 wheel 0 Apr 28 10:17 My Documents
Finder error -43 when I attempt to copy to
~/Volumes/ndrive/My Documents/Original comment by grahampe...@gmail.com on 28 Apr 2007 at 9:22
GoogleCodeExporter
commented
9 years ago Comparing the Finder error with
cp at the command line and
opening, editing and saving with TextEdit.app
---------------------------------------------
grahamperrin:~/Volumes gjp22$ cp ~/Desktop/test.txt ndrive/My\ Documents/
grahamperrin:~/Volumes gjp22$ ls -al ndrive/My\ Documents/
total 8
drwxrwxrwx 1 38091 wheel 0 Apr 28 10:23 .
drwxrwxrwx 1 38091 wheel 0 Apr 27 20:47 ..
dr-xr-xr-x 1 38091 wheel 0 Mar 21 13:59 My Music
-rwxrwxrwx 1 38091 wheel 4 Apr 28 10:23 test.txt
###
I then used TextEdit.app to edit and save test.txt
then reviewed and removed at the command line --
grahamperrin:~/Volumes gjp22$ more ndrive/My\ Documents/test.txt
test
edit
save
grahamperrin:~/Volumes gjp22$ ls -al ndrive/My\ Documents/
total 8
drwxrwxrwx 1 38091 wheel 0 Apr 28 10:24 .
drwxrwxrwx 1 38091 wheel 0 Apr 27 20:47 ..
dr-xr-xr-x 1 38091 wheel 0 Mar 21 13:59 My Music
-rwxrwxrwx 1 38091 wheel 14 Apr 28 10:24 test.txt
grahamperrin:~/Volumes gjp22$ more ndrive/My\ Documents/test.txt
test
edit
save
grahamperrin:~/Volumes gjp22$ rm ndrive/My\ Documents/test.txt
###
... so in this environment, so far
* it's only Finder that presents an error
* and it coincides with presence of a dot underscore file
I might understand the presence of
._test.txt if test.txt had a resource fork, but it does not.
###
I wonder, what will happen if I try to copy an existing
._ file using cp at the command line to this particular server?
Watch this space...Original comment by grahampe...@gmail.com on 28 Apr 2007 at 9:31
GoogleCodeExporter
commented
9 years ago Below, I copy (second) a .webloc file and (first) its dot underscore
counterpart
from a volume keeler that is mounted via MacFusion
to the volume ndrive that Finder is having trouble with...
grahamperrin:~/Volumes gjp22$ cd ndrive/My\ Documents/
grahamperrin:~/Volumes/ndrive/My Documents gjp22$ cp
/Volumes/keeler/._MacFusion.webloc .
grahamperrin:~/Volumes/ndrive/My Documents gjp22$ cp
/Volumes/keeler/MacFusion.webloc .
grahamperrin:~/Volumes/ndrive/My Documents gjp22$ ls -al
total 0
drwxrwxrwx 1 38091 wheel 0 Apr 28 10:46 .
drwxrwxrwx 1 38091 wheel 0 Apr 27 20:47 ..
-rwxrwxrwx 1 38091 wheel 0 Apr 28 10:46 ._MacFusion.webloc
-rwxrwxrwx 1 38091 wheel 0 Apr 28 10:46 MacFusion.webloc
dr-xr-xr-x 1 38091 wheel 0 Mar 21 13:59 My Music
then if I attempt to view that directory in Finder, it beachballs
^^^ interesting ^^^
and I'm waiting ... for the
Continue to wait'/Eject dialogue to appear, but it has not
^^^ interesting ^^^
so I go back to Terminal with the aim of removing
._MacFusion.webloc
grahamperrin:~/Volumes/ndrive/My Documents gjp22$ rm ._
^^^ but Terminal is stuck at that point ^^^
so in Cyberduck, which already has an open window to that directory, I refresh
the view, and see both files,
but when I try to delete
._MacFusion.webloc
Cyberduck reports
> SSH Error: Cannot delete file
With Terminal stuck at
grahamperrin:~/Volumes/ndrive/My Documents gjp22$ rm ._
I quit from Terminal (interestingly, it does not complain about running
processes)
Cyberduck cannot delete
._MacFusion.webloc
but it can delete
MacFusion.webloc
Through the MacFusion Favorites window I unmount keeler cleanly.
Through Activity viewer I force the remaining sshfs-static process to quit.
Finder continues to beachball...Original comment by grahampe...@gmail.com on 28 Apr 2007 at 9:58
GoogleCodeExporter
commented
9 years ago I force Finder to relaunch.
I'm left with
grahamperrin:~/Volumes gjp22$ ls -l
total 0
d--------- 1 root wheel 0 Jan 1 1970 ndrive
and when I re-mount keeler using MacFusion I find
grahamperrin:~/Volumes gjp22$ ls -l /Volumes/keeler/
ls: : Device not configured
grahamperrin:~/Volumes gjp22$ ls -l /Volumes/
total 8
lrwxr-xr-x 1 root admin 1 Apr 26 18:01 MBP -> /
drwxr-xr-x 6 gjp22 staff 306 Apr 2 19:00 Maxtor
drwxr-xr-x 11 gjp22 staff 476 Apr 5 08:55 Perrin
drwxr-xr-x 103 gjp22 staff 3604 Apr 2 19:00 Tim
drwxrwxr-t 41 root admin 1496 Apr 27 11:27 clone-MBP
drwxrwxr-t 10 root admin 442 Apr 28 03:13 clone-excess
drwxrwxr-t 12 root admin 510 Apr 17 15:14 excess
drwxr-xr-x 11 gjp22 staff 476 Apr 21 12:53 extreme
d--------- 1 root wheel 0 Jan 1 1970 keeler
so it's time to restart my Mac :-)
In retrospect, I might have done something more graceful than force
sshfs-static to quit.
Would it have been better to
sshfhs -o hard_remove ndrive.uscs.susx.ac.uk
?Original comment by grahampe...@gmail.com on 28 Apr 2007 at 10:11
GoogleCodeExporter
commented
9 years ago Let's compare (1) the result of the earlier cp
with (2) the directory listings for the files at their source:
(1)
grahamperrin:~/Volumes/ndrive/My Documents gjp22$ cp
/Volumes/keeler/._MacFusion.webloc .
grahamperrin:~/Volumes/ndrive/My Documents gjp22$ cp
/Volumes/keeler/MacFusion.webloc .
grahamperrin:~/Volumes/ndrive/My Documents gjp22$ ls -al
total 0
drwxrwxrwx 1 38091 wheel 0 Apr 28 10:46 .
drwxrwxrwx 1 38091 wheel 0 Apr 27 20:47 ..
-rwxrwxrwx 1 38091 wheel 0 Apr 28 10:46 ._MacFusion.webloc
-rwxrwxrwx 1 38091 wheel 0 Apr 28 10:46 MacFusion.webloc
(2)
grahamperrin:/Volumes/keeler gjp22$ ls -al MacFusion.webloc
-rw-r--r-- 1 gjp22 111 0 Apr 27 04:16 MacFusion.webloc
grahamperrin:/Volumes/keeler gjp22$ ls -al ._MacFusion.webloc
-rw-r--r-- 1 gjp22 111 811 Apr 27 04:18 ._MacFusion.webloc
The cp was _apparently_ successful (no error presented)
for MacFusion.webloc and
for its dot underscore counterpart _but_ on closer inspection,
-rwxrwxrwx 1 38091 wheel 0 Apr 28 10:46 ._MacFusion.webloc
was reduced in size from 811 to 0
(That adds some context to what might have been another issue, which I had
deferred reporting ... I have
stumbled across some webloc files which are damaged. See attached PNG. If these
have lost all bytes from
their resource fork, that would make sense. But I'm not suggesting that sshfs
or MacFUSE caused the loss --
it's equally possible that they lost their resource fork bytes long ago.)Original comment by grahampe...@gmail.com on 28 Apr 2007 at 10:36
Attachments:
GoogleCodeExporter
commented
9 years ago > not suggesting that sshfs or MacFUSE caused the loss -- it's equally
> possible that they lost their resource fork bytes long ago
OT, Cyberduck could have been responsible for that loss. I just confirmed that
it silently copies only the data
fork of files with resource forks. Explained at
<http://trac.cyberduck.ch/ticket/374>. Not a MacFUSE/sshfs issue
:-)Original comment by grahampe...@gmail.com on 28 Apr 2007 at 10:48
GoogleCodeExporter
commented
9 years ago OK, big news. The errors are not limited to MacFUSE/sshfs.
Fugu successfully copies the text only file (no resource fork) to My Documents
on ndrive, but reports an error
> Couldn't fsetstat: No such file or directory
The same results occur whether I (a) copy within Fugu -- drag and drop from
left pane to right pane -- or (b)
drag from Finder to Fugu.
Cyberduck uploads test.txt to ndrive without error.
Fetch uploads test.txt to ndrive without error.
Summary
-------
1) Fugu copies the file to ndrive, but reports an error
2) MacFUSE/sshfs fails to copy the file.
Action
------
Re <http://www.sussex.ac.uk/its/facilities/mac/page.php?pageID=5> Fugu is
amongst the standard software
on IT Services equipment at University of Sussex so I'm submitting a ticket for
investigation by IT Services.
I'll write again with a note of the University of Sussex reference for the
issue.
Best regards
GrahamOriginal comment by grahampe...@gmail.com on 28 Apr 2007 at 11:08
GoogleCodeExporter
commented
9 years ago Our reference is [sussex.ac.uk #12683]. It's a closed system but FYI I have
attached a .webarchive of the
ticket's opening.
On one hand I have a gut feeling that
Finder error -43 and
Fugu error Couldn't fsetstat: No such file or directory
have something to do with ndrive's response to dot underscore files.
On the other hand, there's a dot underscore file at the root of my home
directory,
grahamperrin:/Volumes/ndrive gjp22$ ls -al
total 16
drwxrwxrwx 1 38091 wheel 0 Apr 28 11:58 .
-rwxrwxrwx 1 38091 wheel 6148 Apr 27 21:35 .DS_Store
drwxrwxrwx 1 32952 wheel 0 Dec 9 2005 Favorites
drwxrwxrwx 1 38091 wheel 0 Apr 28 12:12 My Documents
Most interesting (to me) that cp at the command line resulted in a zero byte
file.
Let's await a response from IT Services...Original comment by grahampe...@gmail.com on 28 Apr 2007 at 11:25
Attachments:
GoogleCodeExporter
commented
9 years ago > there's a dot underscore file at the root of my home directory,
> -rwxrwxrwx 1 38091 wheel 6148 Apr 27 21:35 .DS_Store
I need better spectactles. That's NOT a dot underscore file, sorry!
It's a dot DS underscore file.
This strengthens my gut feeling that ndrive may be
refusing dot underscore files.
BTW at <http://code.google.com/p/macfuse/issues/detail?id=159#c4> above I was
experimenting as
suggeested with the -onovncache option but in some of the subsequent tests,
ndrive was mounted using
MacFusion. Original comment by grahampe...@gmail.com on 28 Apr 2007 at 11:37
GoogleCodeExporter
commented
9 years ago Google led me to 25.28 at
<http://www.nmrc.org/pub/faq/hackfaq/hackfaq-25.html>:
> A hacker can make changes to the resource fork files without having
> modify rights. If write rights are removed, the files are secure,
> but nothing can be added to the directory.
I wonder if those rights have been removed by the server administrators? Let's
await their response.
Key point I suppose is that in some environments, Finder may be using dot
underscore files even when no
resource fork exists. Original comment by grahampe...@gmail.com on 28 Apr 2007 at 12:06
GoogleCodeExporter
commented
9 years ago This particular server aside: my interpretation of
<http://www.nmrc.org/pub/faq/hackfaq/hackfaq-25.html> is that some Novell
servers can't be properly
secured unless the administrator refuses write privileges for ._ files.
In which case, a remote directory that is in
drwx...... mode ("you can write here") will
UNEXPECTEDLY DENY write privileges.
That would almost certainly account for Finder error -43
but: the Finder dialogue is non-explicit. (Fair enough, the denial is
unexpected, unexplained; I had to trawl
the Internet for a possible explanation.) For me, the worst aspect was not
knowing whether the problem was
at the (local) source or the (remote) destination. Further confused by
different symptoms/results when I copy
a .webloc file.
As a request for enhancement to MacFUSE, please, I'd like to suggest a dialogue
box:
| The {protocol} service at {host.name.or.ip.address}
| behaves unexpectedly in this environment. Please
| contact your service administrator for advice.
That could equally be a RFE to Finder, but I guess that:
a) explaining the unexpected is not high on the agenda of Finder developers
and
b) a simple GUI dialogue from MacFUSE suggesting a server-side issue will be
far more user-friendly than
what we currently get from Finder.
I should add that Finder error -43 is now, for me, extraordinarily rare. I
suspect that MacFUSE (+ use of GUI
applications such as Finder or Fugu) may become the environment in which error
-43 is most commonly
encountered.
Present a dialogue steering users in the right direction, gain kudos from users
of Fugu and other applications
that can't explain the unexpected :)Original comment by grahampe...@gmail.com on 4 May 2007 at 8:04
GoogleCodeExporter
commented
9 years ago <http://pastie.textmate.org/59114> shows behaviour when copying to single-fork
file to a server that does not
present problems.
Focus: line 558
CREATE[3165296] flags: 0x202 /12683/._test-TextWrangler.txt
-- but the dot underscore file is not present (not required) at the destination
following the successful copy. Original comment by grahampe...@gmail.com on 5 May 2007 at 1:06
GoogleCodeExporter
commented
9 years ago MacFUSE 0.3.0
MacFusion 1.1 Beta 2 revision 210 checked out from SVN.
The SFTP server in question ('ndrive') has been reset but problems persist.
Finder can not copy (upload) to the
volume. I guess that my ticket [sussex.ac.uk #12683] was missed or
misinterpreted by service administrators,
so I have re-opened the ticket with another summary explanation. I await their
response.
Fugu
----
As before, Fugu is fine for reading and removing. As before, the error appears
whenever I perform an upload:
> Couldn't fsetstat: No such file or directory
-- and the upload is successful despite the presentation of the error.
Finder
------
Now, Finder presents something other than the -43 error. It still fails to copy
to ndrive but the error is
> Copy
> The operation cannot be completed because you do not have
> sufficient privileges for some of the items.
> [OK]
The unexpected message re: privileges is harmonious with my
_assumption_ that despite
drwxrwxrwx
for most directories in my home directory,
if I attempt a Finder copy to any such directory then
write (w) access is DENIED for any file with a
._ dot underscore prefix
(Finder appears to check for writeability of ._ files, even when no resource
fork is to be copied.)
On the affected volume:
Finder can read, rename and remove existing files.
Copy is the problem
I wonder whether the error presented by Finder is more descriptive
* since the SFTP server reset
* since to updates to MacFUSE and to MacFusion
* or some combination of all three.
Comparing MacFUSE and MacFusion with Fetch
------------------------------------------
If I attempt to use Finder to copy to ndrive
foo.webloc (which AFAIK has data in its resource fork only)
the resulting error is
> Copy
> The operation cannot be completed because you do not have
> sufficient privileges for some of the items.
> [OK]
If I use Fetch to upload to ndrive
foo.webloc
the successful result is
foo.webloc.sitx
My interpretation: in this respect, Fetch is more resource-fork savvy than
Finder. Finder seems to _assume_
the presence of a resource fork for _any_ file copied (even files that have no
resource fork) _prior_ to (but not
following) a copy operation.
MacFusion version
-----------------
[grahamperrin:~/Developer] gjp22% svn info macfusion
Path: macfusion
URL: http://macfusion.googlecode.com/svn/trunk
Repository Root: http://macfusion.googlecode.com/svn
Repository UUID: a94ec7ac-d928-0410-bd00-8782369af1f7
Revision: 210
Node Kind: directory
Schedule: normal
Last Changed Author: mgorbach
Last Changed Rev: 206
Last Changed Date: 2007-05-17 01:40:29 +0100 (Thu, 17 May 2007)Original comment by grahampe...@gmail.com on 18 May 2007 at 5:26
GoogleCodeExporter
commented
9 years ago See also MacFusion issue one hundred and fifteen
<http://code.google.com/p/macfusion/issues/detail?id=115>.Original comment by grahampe...@gmail.com on 20 May 2007 at 10:02
GoogleCodeExporter
commented
9 years ago At <http://pastie.textmate.org/63697> the result of a failed attempt to copy a
single-fork file
test.txt
to the root of the affected volume (ndrive). At a glance, nothing new. At line
43 of the pastie,
ndrive: CREATE[3153104] flags: 0x202 /._test.txt
Finder copy to the volume is unsuccessful (as always with this particular
server)
but now, no error code -43
Finder presents the following error:
> Copy
> The operation cannot be completed because you do not have
> sufficient privileges for some of the items.
> [OK]
Next actions: Michael Gorbach may discuss with some experts. Graham Perrin
awaiting advice from service
administrators. Graham will bear this MacFUSE issue 159 in mind when he reviews
MacFusion issue_115.
## Environment
MacFUSE 0.3.0, Mac OS X 10.4.9, MacFusion 1.1Original comment by grahampe...@gmail.com on 22 May 2007 at 10:54
GoogleCodeExporter
commented
9 years ago Before clearing (OK'ing) the error dialogue in Finder,
at <http://code.google.com/p/macfuse/issues/detail?id=159#c19> a Terminal view
of both forks relating to
the single fork file
For an alternative view, I used Cyberduck to edit (view) the remote copy of
._test.txt
in TextWranger, which presented a more human readable view of the 82 B file:
Original comment by grahampe...@gmail.com on 22 May 2007 at 11:02
GoogleCodeExporter
commented
9 years ago * correction, that Terminal view is represented at
<http://pastie.textmate.org/63701>Original comment by grahampe...@gmail.com on 22 May 2007 at 11:03
GoogleCodeExporter
commented
9 years ago My comment at
<http://code.google.com/p/macfuse/issues/detail?id=159#c19>
was apparently scrambled :(
At that point in the test,
before clearing the error from Finder,
._test.txt contained the following human-readable text:
Original comment by grahampe...@gmail.com on 23 May 2007 at 12:29
GoogleCodeExporter
commented
9 years ago Let's try again
(that 'human-readable text' evidently included enough invisible
non-ASCII characters to mess with the comments process)...
##
At that point in the test,
before clearing the error from Finder,
._test.txt contained the following human-readable text:
Original comment by grahampe...@gmail.com on 23 May 2007 at 6:36
GoogleCodeExporter
commented
9 years ago brokMACS
The file type
brok
is not listed amongst my file types (viewed by RCDefaultApp)
but I *do* recognise the creator code
MACS
Re: brok let's consider:
<http://myztik.katan.com/?p=106>
<http://lists.apple.com/archives/carbon-dev/2005/Mar/msg00114.html>
<http://www.noodlesoft.com/blog/2006/11/07/antisocial-software/>
<http://www.cocoabuilder.com/archive/message/cocoa/2007/2/17/178912>
Re: bzy let's consider:
<http://www.cocoabuilder.com/archive/message/cocoa/2007/2/17/178912>
<http://developer.apple.com/documentation/Carbon/Reference/Finder_Interface/Refe
rence/reference.html>
<http://developer.apple.com/technotes/tn/tn1142.html>
!!
IF on a remote single-fork file system Finder properly uses a
._foo.bar counterpart to
foo.bar *whilst* foo.bar is being copied
to _signify business_ (a file that busy)
THEN for an SSH or SFTP _server_ that imposes limits, for example
<http://code.google.com/p/macfusion/issues/detail?id=115>
> xbox can only handle one ftp session at a time
Finder may interpret the server's failure to *concurrently* handle
both
._foo.bar
and
foo.bar
as some kind of failure to write foo.bar alone.
##
The preference expressed but _not recommended_ at
<http://docs.info.apple.com/article.html?artnum=301711> suppresses
.DS_Store
but not
._
If there is a hack to suppress
._
then I should NOT recommend it; if the hunches at
<http://myztik.katan.com/?p=106> are correct then
._
is Finder's track record of whether a file has been (or is being) correctly
copied.
##
I also note but do not suggest reading
<http://developer.apple.com/technotes/tn/tn2045.html>
<http://developer.apple.com/documentation/Carbon/Reference/Drag_Manager/drag_man
ager_ref.pdf>
<http://developer.apple.com/documentation/mac/pdf/ResEditReference.pdf>Original comment by grahampe...@gmail.com on 23 May 2007 at 6:37
GoogleCodeExporter
commented
9 years ago -o noapplespecial
results in a different type of error message from Finder:
> Copy
> You cannot copy some of these items to the destination because
> their names are too long or contain invalid characters for the
> destination. Do you want to skip copying these items and
> continue copying the other items?
> [Stop] [Continue]
IF Continue
THEN foo.bar is created
BUT the data fork of foo.bar is empty at the destination.
Original comment by grahampe...@gmail.com on 23 May 2007 at 6:53
GoogleCodeExporter
commented
9 years ago On my local HFS+ volume I touched (created)
._foo.bar
but not
foo.bar
Then used Cyberduck, preferring to view hidden files, to upload
._foo.bar
alone to the SFTP server, the upload was successful.
I then preferred to view hidden files in Finder, and attempted to copy
._foo.bar
to the volume, copy failed.
I used TextWrangler to add text to the local
._foo.bar
then repeated the upload using Cyberduck
then used Cyberduck to read the remote copy into TextWrangler
(Cyberduck caches a copy locally for such purposes),
this proved that
._foo.bar
can contain data on the remote volume
My suspicion that the service disallows
._ files
is probably disproved, but there remains the
failure to copy using Finder.
For now, I'm focuing my thoughts on the
brokMACS
bzy
possibilities. Original comment by grahampe...@gmail.com on 23 May 2007 at 8:21
GoogleCodeExporter
commented
9 years ago For the record: the Finder attempt to copy
._foo.bar
alone results in
> Copy
> The operation cannot be completed because you do not have
> sufficient privileges for some of the items.
> [OK]
and a Cyberduck view of the remote files, before I [OK] that dialogue reveals
._foo.bar
with its contents (two words "hello world")
._._foo.bar
with binary characters and the human-readable text
brokMACS
##
After I OK'd the dialogue
._foo.bar
was removed but
._._foo.bar remained as debris so I'll attempt to attach it to this comment...
fair enough, my Firefox dialogue won't recognise a
._._
file so I have zipped it and given it a more acceptable name.Original comment by grahampe...@gmail.com on 23 May 2007 at 8:37
Attachments:
GoogleCodeExporter
commented
9 years ago Re <http://code.google.com/p/macfuse/wiki/CHANGELOG>
I'll review this issue 159 after the release of MacFUSE 0.4.0 and a compatible
version of MacFusion.
As this particular SFTP service is unpredictable, I don't place a high priority
on explaining or resolving the issue. Original comment by grahampe...@gmail.com on 4 Jun 2007 at 2:14
GoogleCodeExporter
commented
9 years ago An administrator of SFTP and FTP service at ndrive.uscs.susx.ac.uk has
explained the situation to me.
Without going into detail:
keyword is NCP — Novell Core Protocol.
Advice is to *not* seek information on the subject, as NCP is a closed
proprietary protocol about which there
has arisen much mis-information.
The long term plan is to have an improved service. Already WIP.
All things considered, I'm perfectly happy with this.
Amit: if you'd like to invalidate this MacFUSE issue 159
as I have invalidated MacFusion_issue_182
<http://code.google.com/p/macfusion/issues/detail?id=182>
then please, go ahead.
Should future puzzles arise — keywords Novell and NCP —
we can treat both issues as reference items.
##
OT from this issue:
I'm glad to say that there are very few remaining 'puzzles' in the MacFusion
area.
There's plenty of work for us to do, but much of now boils down to
in-application Help and documentation.
Kind regards
GrahamOriginal comment by grahampe...@gmail.com on 8 Jun 2007 at 3:57
GoogleCodeExporter
commented
9 years ago Original comment by si...@gmail.com on 11 Jun 2007 at 5:28
Original issue reported on code.google.com by
grahampe...@gmail.comon 27 Apr 2007 at 9:05