Hi Everyone, I am using MacPorts' fuse + sshfs to mount several remote directories from various Linux servers. most running OpenSSH 3.8. When I edit textfiles (typically C++ or python source code) and delete some bytes in the file, the file on the server sometimes has spurious characters at the end of the file, often a colon (":"), for example. Is this a know issue? Is this an issue of MacPorts, FUSE (MacFUSE ?), sshfs? Where else should I ask if this is not the appropriate mailing list? Greetings, Jochen -- Einigkeit und Recht und Freiheit http://www.Jochen- Kuepper.de Liberté, Égalité, Fraternité GnuPG key: CC1B0B4D Sex, drugs and rock-n-roll
I recommend asking on the MacFUSE google group. On May 2, 2007, at 12:06 PM, Jochen Küpper wrote:
Hi Everyone,
I am using MacPorts' fuse + sshfs to mount several remote directories from various Linux servers. most running OpenSSH 3.8.
When I edit textfiles (typically C++ or python source code) and delete some bytes in the file, the file on the server sometimes has spurious characters at the end of the file, often a colon (":"), for example.
Is this a know issue? Is this an issue of MacPorts, FUSE (MacFUSE ?), sshfs? Where else should I ask if this is not the appropriate mailing list?
-- Kevin Ballard http://kevin.sb.org eridius@macports.org http://www.tildesoft.com
My bigger question is how people are managing to use anything depending on fuse at all, at the moment. On 10.4.9, I get the following build error for libfuse: /opt/local/var/db/dports/build/ _User_jkh_Src_macports_dports_fuse_fusefs/work/fusefs/fuse_knote.h: 17: error: redefinition of 'struct klist' /opt/local/var/db/dports/build/ _Users_jkh_Src_macports_dports_fuse_fusefs/work/fusefs/fuse_knote.h: 19: error: redefinition of 'struct filterops' /opt/local/var/db/dports/build/ _Users_jkh_Src_macports_dports_fuse_fusefs/work/fusefs/fuse_knote.h: 26: error: redefinition of 'struct kqtailq' /opt/local/var/db/dports/build/ _Users_jkh_Src_macports_dports_fuse_fusefs/work/fusefs/fuse_knote.h: 28: error: redefinition of 'struct knote' I've just been assuming that the fuse stuff is broken right now (don't even ask how it horks up on Leopard - not even close to building there). Are others getting better results with fuse and Tiger? - Jordan On May 3, 2007, at 3:09 PM, Kevin Ballard wrote:
I recommend asking on the MacFUSE google group.
On May 2, 2007, at 12:06 PM, Jochen Küpper wrote:
Hi Everyone,
I am using MacPorts' fuse + sshfs to mount several remote directories from various Linux servers. most running OpenSSH 3.8.
When I edit textfiles (typically C++ or python source code) and delete some bytes in the file, the file on the server sometimes has spurious characters at the end of the file, often a colon (":"), for example.
Is this a know issue? Is this an issue of MacPorts, FUSE (MacFUSE ?), sshfs? Where else should I ask if this is not the appropriate mailing list?
-- Kevin Ballard http://kevin.sb.org eridius@macports.org http://www.tildesoft.com
_______________________________________________ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
On May 3, 2007, at 8:21 PM, Jordan K. Hubbard wrote:
I've just been assuming that the fuse stuff is broken right now (don't even ask how it horks up on Leopard - not even close to building there). Are others getting better results with fuse and Tiger?
port build works but port install fails. Stuff like this: /opt/local/var/db/dports/build/ _opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dp orts_fuse_fusefs/work/fusefs/fuse_ipc.c:17:52: error: UserNotification/kUNCUserNotifications.h: No such file or directory looks odd. Those functions/definitions do exist, apparently. white:~/Library/Logs/CrashReporter root# mdfind kUNCUserNotifications /Developer/SDKs/MacOSX10.3.9.sdk/System/Library/Frameworks/ Kernel.framework/Versions/A/Headers/UserNotification/ KUNCUserNotifications.h /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/ Kernel.framework/Versions/A/Headers/UserNotification/ KUNCUserNotifications.h /opt/local/var/db/dports/build/ _opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dp orts_fuse_fusefs/work/fusefs/fuse_ipc.c -- Paul Beard words: http://paulbeard.org/wordpress pictures: http://www.flickr.com/photos/pdb206/ Are you trying to win an argument or solve a problem?
paul beard wrote:
On May 3, 2007, at 8:21 PM, Jordan K. Hubbard wrote:
I've just been assuming that the fuse stuff is broken right now (don't even ask how it horks up on Leopard - not even close to building there). Are others getting better results with fuse and Tiger?
port build works but port install fails.
Builds and installs fine on Darwin Kernel Version 8.9.1 (Tiger?). I use OSX (Intel) as the server and mount the directories on Linux machines; no problems so far, though I'm mainly reading. Dave
On 4.5.2007, at 6.21, Jordan K. Hubbard wrote:
My bigger question is how people are managing to use anything depending on fuse at all, at the moment. On 10.4.9, I get the following build error for libfuse:
/opt/local/var/db/dports/build/ _User_jkh_Src_macports_dports_fuse_fusefs/work/fusefs/fuse_knote.h: 17: error: redefinition of 'struct klist' /opt/local/var/db/dports/build/ _Users_jkh_Src_macports_dports_fuse_fusefs/work/fusefs/fuse_knote.h: 19: error: redefinition of 'struct filterops' /opt/local/var/db/dports/build/ _Users_jkh_Src_macports_dports_fuse_fusefs/work/fusefs/fuse_knote.h: 26: error: redefinition of 'struct kqtailq' /opt/local/var/db/dports/build/ _Users_jkh_Src_macports_dports_fuse_fusefs/work/fusefs/fuse_knote.h: 28: error: redefinition of 'struct knote'
I've just been assuming that the fuse stuff is broken right now (don't even ask how it horks up on Leopard - not even close to building there). Are others getting better results with fuse and Tiger?
- Jordan
On May 3, 2007, at 3:09 PM, Kevin Ballard wrote:
I recommend asking on the MacFUSE google group.
On May 2, 2007, at 12:06 PM, Jochen Küpper wrote:
Hi Everyone,
I am using MacPorts' fuse + sshfs to mount several remote directories from various Linux servers. most running OpenSSH 3.8.
When I edit textfiles (typically C++ or python source code) and delete some bytes in the file, the file on the server sometimes has spurious characters at the end of the file, often a colon (":"), for example.
Is this a know issue? Is this an issue of MacPorts, FUSE (MacFUSE ?), sshfs? Where else should I ask if this is not the appropriate mailing list?
-- Hi, I am currently using sshfs daily (depends on libfuse and needs the fusefs kext, too). I don't edit files on sshfs volume, but locally, and then sync. But it works fine, at least for me. ! ! Jyrki Wahlstedt ! skype:jyrkiwahlstedt ! http://www.wahlstedt.fi/jyrki/ ! ! Our life is no dream; but it ought to become one and perhaps will. ! PGP key ID: 0x139CC386 fingerprint: F355 B46F 026C B8C1 89C0 A780 6366 EFD9 139C C386
On 04.05.2007, at 05:21, Jordan K. Hubbard wrote:
My bigger question is how people are managing to use anything depending on fuse at all, at the moment. On 10.4.9, I get the following build error for libfuse:
Well, it simply builds for me on 10.4.9 on G4 and Core Duo systems:
sudo port info fusefs fusefs 0.2.5, fuse/fusefs (Variants: universal, darwin) http://code.google.com/p/macfuse/
MacFUSE implements a mechanism that makes it possible to implement a fully functional file system in a user-space program on Mac OS X (10.4 and above). It aims to be API-compliant with the FUSE (File- system in USErspace) mechanism that originated on Linux. Therefore, many existing FUSE file systems become readily usable on Mac OS X. The core of MacFUSE is in a dynamically loadable kernel extension. Platforms: darwin Maintainers: eridius@macports.org
I am using MacPorts' fuse + sshfs to mount several remote directories from various Linux servers. most running OpenSSH 3.8.
When I edit textfiles (typically C++ or python source code) and delete some bytes in the file, the file on the server sometimes has spurious characters at the end of the file, often a colon (":"), for example.
Btw, I have tracked /most/ of my problems to a single server which is running SSH Version Sun_SSH_1.0.1, protocol versions 1.5/2.0. I'll investigate further wether it might be only the "other" end that is causing problems... Greetings, Jochen -- Einigkeit und Recht und Freiheit http://www.Jochen- Kuepper.de Liberté, Égalité, Fraternité GnuPG key: CC1B0B4D Sex, drugs and rock-n-roll
sshfs working great for me (mounting various linuxes using tiger.9 on both g4 & 5). been doing considerable editing, file manipulation via cli, etc without a hitch (well, i guess running svn-status inside emacs could be a little faster, but sure beats tramp). -emory On May 3, 2007, at 9:21 PM, Jordan K. Hubbard wrote:
My bigger question is how people are managing to use anything depending on fuse at all, at the moment. On 10.4.9, I get the following build error for libfuse:
/opt/local/var/db/dports/build/ _User_jkh_Src_macports_dports_fuse_fusefs/work/fusefs/fuse_knote.h: 17: error: redefinition of 'struct klist' /opt/local/var/db/dports/build/ _Users_jkh_Src_macports_dports_fuse_fusefs/work/fusefs/fuse_knote.h: 19: error: redefinition of 'struct filterops' /opt/local/var/db/dports/build/ _Users_jkh_Src_macports_dports_fuse_fusefs/work/fusefs/fuse_knote.h: 26: error: redefinition of 'struct kqtailq' /opt/local/var/db/dports/build/ _Users_jkh_Src_macports_dports_fuse_fusefs/work/fusefs/fuse_knote.h: 28: error: redefinition of 'struct knote'
I've just been assuming that the fuse stuff is broken right now (don't even ask how it horks up on Leopard - not even close to building there). Are others getting better results with fuse and Tiger?
- Jordan
On May 3, 2007, at 3:09 PM, Kevin Ballard wrote:
I recommend asking on the MacFUSE google group.
On May 2, 2007, at 12:06 PM, Jochen Küpper wrote:
Hi Everyone,
I am using MacPorts' fuse + sshfs to mount several remote directories from various Linux servers. most running OpenSSH 3.8.
When I edit textfiles (typically C++ or python source code) and delete some bytes in the file, the file on the server sometimes has spurious characters at the end of the file, often a colon (":"), for example.
Is this a know issue? Is this an issue of MacPorts, FUSE (MacFUSE ?), sshfs? Where else should I ask if this is not the appropriate mailing list?
-- Kevin Ballard http://kevin.sb.org eridius@macports.org http://www.tildesoft.com
_______________________________________________ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
_______________________________________________ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
That's pretty weird. It works fine for me. Perhaps __FreeBSD__=10 isn't getting defined for you? I left it out of the explicit arguments for libfuse because libfuse normally picks that up from fusefs via pkg-config. Maybe you have a problem with that? Try running `pkg-config --cflags fuse`. It should give you something like -D__FreeBSD__=10 -D_FILE_OFFSET_BITS=64 -I/opt/local/include/fuse On May 3, 2007, at 11:21 PM, Jordan K. Hubbard wrote:
My bigger question is how people are managing to use anything depending on fuse at all, at the moment. On 10.4.9, I get the following build error for libfuse:
/opt/local/var/db/dports/build/ _User_jkh_Src_macports_dports_fuse_fusefs/work/fusefs/fuse_knote.h: 17: error: redefinition of 'struct klist' /opt/local/var/db/dports/build/ _Users_jkh_Src_macports_dports_fuse_fusefs/work/fusefs/fuse_knote.h: 19: error: redefinition of 'struct filterops' /opt/local/var/db/dports/build/ _Users_jkh_Src_macports_dports_fuse_fusefs/work/fusefs/fuse_knote.h: 26: error: redefinition of 'struct kqtailq' /opt/local/var/db/dports/build/ _Users_jkh_Src_macports_dports_fuse_fusefs/work/fusefs/fuse_knote.h: 28: error: redefinition of 'struct knote'
I've just been assuming that the fuse stuff is broken right now (don't even ask how it horks up on Leopard - not even close to building there). Are others getting better results with fuse and Tiger?
-- Kevin Ballard http://kevin.sb.org eridius@macports.org http://www.tildesoft.com
On 4.5.2007, at 6.21, Jordan K. Hubbard wrote:
My bigger question is how people are managing to use anything depending on fuse at all, at the moment. On 10.4.9, I get the following build error for libfuse:
/opt/local/var/db/dports/build/ _User_jkh_Src_macports_dports_fuse_fusefs/work/fusefs/fuse_knote.h: 17: error: redefinition of 'struct klist' /opt/local/var/db/dports/build/ _Users_jkh_Src_macports_dports_fuse_fusefs/work/fusefs/fuse_knote.h: 19: error: redefinition of 'struct filterops' /opt/local/var/db/dports/build/ _Users_jkh_Src_macports_dports_fuse_fusefs/work/fusefs/fuse_knote.h: 26: error: redefinition of 'struct kqtailq' /opt/local/var/db/dports/build/ _Users_jkh_Src_macports_dports_fuse_fusefs/work/fusefs/fuse_knote.h: 28: error: redefinition of 'struct knote'
I've just been assuming that the fuse stuff is broken right now (don't even ask how it horks up on Leopard - not even close to building there). Are others getting better results with fuse and Tiger?
- Jordan
On May 3, 2007, at 3:09 PM, Kevin Ballard wrote:
I recommend asking on the MacFUSE google group.
On May 2, 2007, at 12:06 PM, Jochen Küpper wrote:
Hi Everyone,
I am using MacPorts' fuse + sshfs to mount several remote directories from various Linux servers. most running OpenSSH 3.8.
When I edit textfiles (typically C++ or python source code) and delete some bytes in the file, the file on the server sometimes has spurious characters at the end of the file, often a colon (":"), for example.
Is this a know issue? Is this an issue of MacPorts, FUSE (MacFUSE ?), sshfs? Where else should I ask if this is not the appropriate mailing list?
Hi all, there seems to be one small problem with the package. It does not build on case-sensitive filesystems! It failed in my home laptop, though there were no problems in my work laptop. The main difference between the units is the filesystem, at work I didn't install the system and the filesystem is the default, at home I use the case- sensitive variant (having a still longer UNIX than Mac background). I looked at the fusefs package and there is an include (in fuse_ipc.c): #include <UserNotification/kUNCUserNotifications.h>
the file is actually: /System/Library/Frameworks/Kernel.framework/Versions/A/Headers/ UserNotification/KUNCUserNotifications.h I couldn't yet check whether that fixes the problem, but it seems promising. Every port should build on case-sensitive filesystems, too!!! ! ! Jyrki Wahlstedt ! skype:jyrkiwahlstedt ! http://www.wahlstedt.fi/jyrki/ ! ! Our life is no dream; but it ought to become one and perhaps will. ! PGP key ID: 0x139CC386 fingerprint: F355 B46F 026C B8C1 89C0 A780 6366 EFD9 139C C386
On May 7, 2007, at 01:35, Jyrki Wahlstedt wrote:
there seems to be one small problem with the package. It does not build on case-sensitive filesystems! It failed in my home laptop, though there were no problems in my work laptop. The main difference between the units is the filesystem, at work I didn't install the system and the filesystem is the default, at home I use the case-sensitive variant (having a still longer UNIX than Mac background). I looked at the fusefs package and there is an include (in fuse_ipc.c): #include <UserNotification/kUNCUserNotifications.h>
the file is actually: /System/Library/Frameworks/Kernel.framework/Versions/A/Headers/ UserNotification/KUNCUserNotifications.h
I couldn't yet check whether that fixes the problem, but it seems promising.
Sounds like this problem is not specific to MacPorts, and that it should be reported to the upstream maintainers of fusefs.
Every port should build on case-sensitive filesystems, too!!!
Perhaps. But note that Apple used to specifically tell you not to use case-sensitive HFS+ for your boot volume in the 10.3 days. See the first paragraph: http://docs.info.apple.com/article.html?artnum=107863 I can find virtually no other information in the knowledge base about case-sensitive HFS+, including whether or not that directive still applies to 10.4 and later. Note also that probably none of the MacPorts contributors have case- sensitive HFS+ setups, so probably nobody other than you will discover or be affected by such problems. While I would expect such problems to be rare, they would be nonexistent if you used the normal case-insensitive HFS+.
On 7.5.2007, at 11.27, Ryan Schmidt wrote:
On May 7, 2007, at 01:35, Jyrki Wahlstedt wrote:
there seems to be one small problem with the package. It does not build on case-sensitive filesystems! It failed in my home laptop, though there were no problems in my work laptop. The main difference between the units is the filesystem, at work I didn't install the system and the filesystem is the default, at home I use the case-sensitive variant (having a still longer UNIX than Mac background). I looked at the fusefs package and there is an include (in fuse_ipc.c): #include <UserNotification/kUNCUserNotifications.h>
the file is actually: /System/Library/Frameworks/Kernel.framework/Versions/A/Headers/ UserNotification/KUNCUserNotifications.h
I couldn't yet check whether that fixes the problem, but it seems promising.
Sounds like this problem is not specific to MacPorts, and that it should be reported to the upstream maintainers of fusefs.
Quite true.
Every port should build on case-sensitive filesystems, too!!!
Perhaps. But note that Apple used to specifically tell you not to use case-sensitive HFS+ for your boot volume in the 10.3 days. See the first paragraph:
This is for Server only. And the Installer should forbid one to do this. As I could install a system with case-sensitive filesystem, it should work and be supported.
I can find virtually no other information in the knowledge base about case-sensitive HFS+, including whether or not that directive still applies to 10.4 and later.
Note also that probably none of the MacPorts contributors have case- sensitive HFS+ setups, so probably nobody other than you will discover or be affected by such problems. While I would expect such problems to be rare, they would be nonexistent if you used the normal case-insensitive HFS+.
This has been a problem with some other ports as well, e.g. TeXShop had a problem due to a case-sensitivity in some filenames. Filesystems being case-sensitive or not is a debate not worth going into here, suffice it to repeat that the ports really should work in both. ! ! Jyrki Wahlstedt ! skype:jyrkiwahlstedt ! http://www.wahlstedt.fi/jyrki/ ! ! Our life is no dream; but it ought to become one and perhaps will. ! PGP key ID: 0x139CC386 fingerprint: F355 B46F 026C B8C1 89C0 A780 6366 EFD9 139C C386
On May 7, 2007, at 01:27, Ryan Schmidt wrote:
Note also that probably none of the MacPorts contributors have case- sensitive HFS+ setups, so probably nobody other than you will discover or be affected by such problems. While I would expect such problems to be rare, they would be nonexistent if you used the normal case-insensitive HFS+.
Heh. Actually: http://trac.macports.org/projects/macports/browser/trunk/dports/ devel/cvs-port Was named 'cvs-port' as to not conflict with 'CVS' the directory, when we used CVS ('CVS' vs. 'cvs'). On the flip side, some people are going to use case-sensitive file systems. There doesn't seem like a particularly good reason to not support them, since 9 times out of 10, failure to work with a case- sensitive file system is indicative of a bug. -landonf
On May 7, 2007, at 1:27 AM, Ryan Schmidt wrote:
Perhaps. But note that Apple used to specifically tell you not to use case-sensitive HFS+ for your boot volume in the 10.3 days. See the first paragraph:
While this is true, "Apple" also goes out of its way to fix build problems (internally) that result from case sensitivity gone awry. I don't think MacPorts should hide behind this one - it's not a very future-proof strategy. I'll say no more. :-) - Jordan
On 7.5.2007, at 9.35, Jyrki Wahlstedt wrote:
On 4.5.2007, at 6.21, Jordan K. Hubbard wrote:
My bigger question is how people are managing to use anything depending on fuse at all, at the moment. On 10.4.9, I get the following build error for libfuse:
/opt/local/var/db/dports/build/ _User_jkh_Src_macports_dports_fuse_fusefs/work/fusefs/fuse_knote.h: 17: error: redefinition of 'struct klist' /opt/local/var/db/dports/build/ _Users_jkh_Src_macports_dports_fuse_fusefs/work/fusefs/ fuse_knote.h:19: error: redefinition of 'struct filterops' /opt/local/var/db/dports/build/ _Users_jkh_Src_macports_dports_fuse_fusefs/work/fusefs/ fuse_knote.h:26: error: redefinition of 'struct kqtailq' /opt/local/var/db/dports/build/ _Users_jkh_Src_macports_dports_fuse_fusefs/work/fusefs/ fuse_knote.h:28: error: redefinition of 'struct knote'
I've just been assuming that the fuse stuff is broken right now (don't even ask how it horks up on Leopard - not even close to building there). Are others getting better results with fuse and Tiger?
- Jordan
On May 3, 2007, at 3:09 PM, Kevin Ballard wrote:
I recommend asking on the MacFUSE google group.
<snip>
Hi all, there seems to be one small problem with the package. It does not build on case-sensitive filesystems! It failed in my home laptop, though there were no problems in my work laptop. The main difference between the units is the filesystem, at work I didn't install the system and the filesystem is the default, at home I use the case-sensitive variant (having a still longer UNIX than Mac background). I looked at the fusefs package and there is an include (in fuse_ipc.c): #include <UserNotification/kUNCUserNotifications.h>
the file is actually: /System/Library/Frameworks/Kernel.framework/Versions/A/Headers/ UserNotification/KUNCUserNotifications.h
I couldn't yet check whether that fixes the problem, but it seems promising. Every port should build on case-sensitive filesystems, too!!! Hi, as a followup: I've verified this, I just built fusefs on my case- sensitive system, created a ticket (#11918) with diff for Portfile and a patch, and also reported this upstream (issue #11, IIRC).
! ! Jyrki Wahlstedt ! skype:jyrkiwahlstedt ! http://www.wahlstedt.fi/jyrki/ ! ! Our life is no dream; but it ought to become one and perhaps will. ! PGP key ID: 0x139CC386 fingerprint: F355 B46F 026C B8C1 89C0 A780 6366 EFD9 139C C386
On 8.5.2007, at 8.20, Jyrki Wahlstedt wrote:
Hi, as a followup: I've verified this, I just built fusefs on my case- sensitive system, created a ticket (#11918) with diff for Portfile and a patch, and also reported this upstream (issue #11, IIRC).
Well, I checked the home site and it seems that fix is included in the next version (0.3.0). ! ! Jyrki Wahlstedt ! skype:jyrkiwahlstedt ! http://www.wahlstedt.fi/jyrki/ ! ! Our life is no dream; but it ought to become one and perhaps will. ! PGP key ID: 0x139CC386 fingerprint: F355 B46F 026C B8C1 89C0 A780 6366 EFD9 139C C386
participants (9)
-
David Liontooth
-
Emory Smith
-
Jochen Küpper
-
Jordan K. Hubbard
-
Jyrki Wahlstedt
-
Kevin Ballard
-
Landon Fuller
-
paul beard
-
Ryan Schmidt