Older

• Dec 01, 2009

  issue 14 (ArchFS should only extract on demand) commented on by gerasiov   -   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=552228

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=552228
• Nov 02, 2009

  issue 24 (Porting archfs for rdiff-backup-1.2.x) reported by iva...@supervisor.sk   -   Hi - im using CentOS 5.4 and there is version of rdiff-backup 1.2.x and i have one question: is any plan for porting archfs to this version of rdiff-backup? This is very good and usefully software and this will help me. Sorry for my bad english.

  Hi - im using CentOS 5.4 and there is version of rdiff-backup 1.2.x and i have one question: is any plan for porting archfs to this version of rdiff-backup? This is very good and usefully software and this will help me. Sorry for my bad english.
• Oct 24, 2009

  issue 23 (archfs uses /tmp, does not honour $TMPDIR) commented on by jon.dowland   -   Patch attached.

  Patch attached.
• Oct 24, 2009

  issue 23 (archfs uses /tmp, does not honour $TMPDIR) reported by jon.dowland   -   What steps will reproduce the problem? 1. define $TMPDIR to something not /tmp 2. use archfs 3. observe use of /tmp What is the expected output? What do you see instead? use $TMPDIR for temporary storage What version of the product are you using? On what operating system? 0.5.4-1 / debian Please provide any additional information below. I've got a patch for this, pending.

  What steps will reproduce the problem? 1. define $TMPDIR to something not /tmp 2. use archfs 3. observe use of /tmp What is the expected output? What do you see instead? use $TMPDIR for temporary storage What version of the product are you using? On what operating system? 0.5.4-1 / debian Please provide any additional information below. I've got a patch for this, pending.
• Oct 24, 2009

  issue 9 (Compile issues on Debian for v0.5.1 & trunk as of 20060226) commented on by jon.dowland   -   The configure script needs rebuilding with a modern autoconf. The Debian package is patched for this.

  The configure script needs rebuilding with a modern autoconf. The Debian package is patched for this.
• Oct 20, 2009

  issue 22 (memory leak?) commented on by kerny404   -   I tried again and yes the problem is with archfs, the memory usage goes to 1Gb or even more and unmounting it doens't appear to free the ram correctly (at least that's what I see using htop). I can't do many tests because it's a delicate machine unfortunately...

  I tried again and yes the problem is with archfs, the memory usage goes to 1Gb or even more and unmounting it doens't appear to free the ram correctly (at least that's what I see using htop). I can't do many tests because it's a delicate machine unfortunately...
• Oct 07, 2009

  issue 22 (memory leak?) reported by kerny404   -   What steps will reproduce the problem? 1. mount few snapshots directory with a lot of data 2. after few hours I see many processes using oom-killer What version of the product are you using? On what operating system? Version 0.5.3 on ubuntu 8.04 64bit Please provide any additional information below. I'm not 100% sure that the problem is generated by archfs, but it's the only thing I've done before seeing this behavior.

  What steps will reproduce the problem? 1. mount few snapshots directory with a lot of data 2. after few hours I see many processes using oom-killer What version of the product are you using? On what operating system? Version 0.5.3 on ubuntu 8.04 64bit Please provide any additional information below. I'm not 100% sure that the problem is generated by archfs, but it's the only thing I've done before seeing this behavior.
• Aug 30, 2009

  issue 18 (owner,group,permissions,acl not shown) commented on by eshkay   -   what is the status on this?

  what is the status on this?
• Aug 18, 2009

  r74 (Setting zero revisions in revision count, so the retriever w...) committed by gruszczy   -   Setting zero revisions in revision count, so the retriever won't fail.

  Setting zero revisions in revision count, so the retriever won't fail.
• Jul 09, 2009

  issue 14 (ArchFS should only extract on demand) commented on by dcl...@pobox.com   -   Hope this summer still holds some free time in store for you :-) I also suffer from this problem - first file system I am trying archfs on is about 100GB with around 30 deltas of 0.25-2GB each, and after an hour filesystem is still not mounted, although it still seems to be extracting stuff so not hung - I don't care about the tmp space usage, but this does seem to make it not so usable in my use case.

  Hope this summer still holds some free time in store for you :-) I also suffer from this problem - first file system I am trying archfs on is about 100GB with around 30 deltas of 0.25-2GB each, and after an hour filesystem is still not mounted, although it still seems to be extracting stuff so not hung - I don't care about the tmp space usage, but this does seem to make it not so usable in my use case.
• May 26, 2009

  r73 ([No log message]) committed by gruszczy   -   [No log message]

  [No log message]
• May 25, 2009

  issue 11 (make wants -D_FILE_OFFSET_BITS=64) commented on by eshkay   -   Sorry for the late response. Your patch works. Thanks.

  Sorry for the late response. Your patch works. Thanks.
• May 20, 2009

  r72 ([No log message]) committed by gruszczy   -   [No log message]

  [No log message]
• May 15, 2009

  r71 ([No log message]) committed by gruszczy   -   [No log message]

  [No log message]
• May 14, 2009

  r70 ([No log message]) committed by gruszczy   -   [No log message]

  [No log message]
• Apr 07, 2009

  issue 21 (Please re-run 'autoconf' in order to generate new configure ...) reported by adferguson   -   Using archfs 0.5.4 on a system with gcc 4.3.2 (eg, Ubuntu 8.10), the included configure script hangs for 60 seconds when running the mktime test. This happens because of a change in how gcc optimizes a strange loop produced by older versions of autoconf. See: https://bugs.launchpad.net/ubuntu/+source/gcc-4.3/+bug/323528 for my analysis. By re-running autoconf to generate a new configure script, this problem went away and the configure script properly detected mktime support. I used autoconf 2.61, which worked great. Thanks, Andrew (rdiff-backup maintainer)

  Using archfs 0.5.4 on a system with gcc 4.3.2 (eg, Ubuntu 8.10), the included configure script hangs for 60 seconds when running the mktime test. This happens because of a change in how gcc optimizes a strange loop produced by older versions of autoconf. See: https://bugs.launchpad.net/ubuntu/+source/gcc-4.3/+bug/323528 for my analysis. By re-running autoconf to generate a new configure script, this problem went away and the configure script properly detected mktime support. I used autoconf 2.61, which worked great. Thanks, Andrew (rdiff-backup maintainer)
• Feb 06, 2009

  issue 11 (make wants -D_FILE_OFFSET_BITS=64) Status changed by artoole   -   Can you try this patch and verify it works? [atoole@ensoft-linux3 archfs]$ diff -cbr 0.5.1 0.5.2 diff -cbr 0.5.1/archfs/configure 0.5.2/archfs/configure *** 0.5.1/archfs/configure Sun Aug 19 00:43:03 2007 --- 0.5.2/archfs/configure Mon Sep 22 22:08:25 2008 *************** *** 6501,6509 **** case $host in ! *-*-linux-*) CFLAGS="-Wall -O3 `pkg-config --cflags fuse` -D_GNU_SOURCE" ! LDFLAGS="`pkg-config --cflags --libs fuse` -lz -D_GNU_SOURCE" ;; *-*-bsd-*) CFLAGS="-Wall -O3 `pkg-config --cflags fuse`" --- 6501,6509 ---- case $host in ! *-*-linux-*) CFLAGS="-Wall -O3 `pkg-config --cflags fuse` -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64" ! LDFLAGS="`pkg-config --cflags --libs fuse` -lz -lfuse -D_GNU_SOURCE" ;; *-*-bsd-*) CFLAGS="-Wall -O3 `pkg-config --cflags fuse`" [atoole@ensoft-linux3 archfs]$

  Status: Started

  Can you try this patch and verify it works? [atoole@ensoft-linux3 archfs]$ diff -cbr 0.5.1 0.5.2 diff -cbr 0.5.1/archfs/configure 0.5.2/archfs/configure *** 0.5.1/archfs/configure Sun Aug 19 00:43:03 2007 --- 0.5.2/archfs/configure Mon Sep 22 22:08:25 2008 *************** *** 6501,6509 **** case $host in ! *-*-linux-*) CFLAGS="-Wall -O3 `pkg-config --cflags fuse` -D_GNU_SOURCE" ! LDFLAGS="`pkg-config --cflags --libs fuse` -lz -D_GNU_SOURCE" ;; *-*-bsd-*) CFLAGS="-Wall -O3 `pkg-config --cflags fuse`" --- 6501,6509 ---- case $host in ! *-*-linux-*) CFLAGS="-Wall -O3 `pkg-config --cflags fuse` -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64" ! LDFLAGS="`pkg-config --cflags --libs fuse` -lz -lfuse -D_GNU_SOURCE" ;; *-*-bsd-*) CFLAGS="-Wall -O3 `pkg-config --cflags fuse`" [atoole@ensoft-linux3 archfs]$

  Status: Started
• Feb 05, 2009

  issue 11 (make wants -D_FILE_OFFSET_BITS=64) commented on by eshkay   -   This bug is back in 0.5.4 ubuntu-server-8.10-amd64

  This bug is back in 0.5.4 ubuntu-server-8.10-amd64
• Feb 03, 2009

  issue 20 (Customizable directory format) reported by jjmaestro   -   Enhancement: This is a "wishlist bug" for archfs to support basic customization of the directory format, so that users that want it as close to the ISO date format as possible can easily pass a formatting string (something like the date formatting string). A quick hack done to the current version of archfs allows this at compilation by simply adding a #define and retouching layout/support.c (see attached patch file). Thanks for all the work in archfs!

  Enhancement: This is a "wishlist bug" for archfs to support basic customization of the directory format, so that users that want it as close to the ISO date format as possible can easily pass a formatting string (something like the date formatting string). A quick hack done to the current version of archfs allows this at compilation by simply adding a #define and retouching layout/support.c (see attached patch file). Thanks for all the work in archfs!
• Jan 12, 2009

  issue 15 (Cannot view archfs through Samba - directories as zero lengt...) commented on by domi...@winkfieldproperties.co.uk   -   In archfs 0.5.3 you can solve this problem by altering revisions.c starting at line 15 thus (thanks to Chris Wilper for this): if (stats->type == S_IFDIR) { stbuf->st_mode = stats->type | 0555; stbuf->st_nlink = 2; } else { stbuf->st_mode = stats->type | 0444; stbuf->st_nlink = 1; }

  In archfs 0.5.3 you can solve this problem by altering revisions.c starting at line 15 thus (thanks to Chris Wilper for this): if (stats->type == S_IFDIR) { stbuf->st_mode = stats->type | 0555; stbuf->st_nlink = 2; } else { stbuf->st_mode = stats->type | 0444; stbuf->st_nlink = 1; }
• Jan 06, 2009

  issue 18 (owner,group,permissions,acl not shown) reported by maxximino   -   rdiff-backup preserves those informations, and those should be visible in the "mounted" repository

  rdiff-backup preserves those informations, and those should be visible in the "mounted" repository
• Nov 30, 2008

  archfs-0.5.4.tar.gz (added required licence information) file uploaded by gruszczy   -  

  Labels: Type-Source OpSys-Linux Featured

  Labels: Type-Source OpSys-Linux Featured
• Nov 20, 2008

  issue 17 (cannot pass command line switches through to fuse (e.g. -oal...) reported by domi...@winkfieldproperties.co.uk   -   What steps will reproduce the problem? Example: to use fuse '-oallow_other' option, try this: archfs -oallow_other /mnt/arch /home/user1/rdiff-repository Error: No such option; see man archfs Compare: sshfs allows a range of switches to be passed through to fuse, including '-oallow_other' (as use '-o allow_other') Please can this be fixed to pass through options to fuse in the way that sshfs does. Note also that 'man archfs' does not work, I think the man file is not included in archfs-0.5.3.tar.gz Please provide any additional information below. workaround for 'oallow_other' option is to change lines 27-29 of archfs.c from: args[2] = "-d"; return fuse_main(2, args, &operations, NULL); to: args[2] = strdup("-oallow_other"); return fuse_main(3, args, &operations, NULL); You must also (as described in fuse documentation) enable user_allow_other in etc/fuse.conf

  What steps will reproduce the problem? Example: to use fuse '-oallow_other' option, try this: archfs -oallow_other /mnt/arch /home/user1/rdiff-repository Error: No such option; see man archfs Compare: sshfs allows a range of switches to be passed through to fuse, including '-oallow_other' (as use '-o allow_other') Please can this be fixed to pass through options to fuse in the way that sshfs does. Note also that 'man archfs' does not work, I think the man file is not included in archfs-0.5.3.tar.gz Please provide any additional information below. workaround for 'oallow_other' option is to change lines 27-29 of archfs.c from: args[2] = "-d"; return fuse_main(2, args, &operations, NULL); to: args[2] = strdup("-oallow_other"); return fuse_main(3, args, &operations, NULL); You must also (as described in fuse documentation) enable user_allow_other in etc/fuse.conf
• Nov 20, 2008

  issue 16 (compile failure with gcc version 4.3.2) reported by domi...@winkfieldproperties.co.uk   -   What steps will reproduce the problem? - with archfs 0.5.3, run ./compile, using gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu11) What is the expected output? What do you see instead? you see: In function ‘open’, inlined from ‘unzip_revs’ at support.c:74: /usr/include/bits/fcntl2.h:51: error: call to ‘__open_missing_mode’ declared with attribute error: open with O_CREAT in second argument needs 3 arguments Please provide any additional information below. This problem does not seem to occur with earlier versions of gcc. The fix (suggested by Andrew Ferguson) is in layout/support.c at line 74, change: if ((descriptor = open(mirror, O_WRONLY | O_CREAT)) == -1) to: if ((descriptor = open(mirror, O_WRONLY | O_CREAT, 0777)) == -1) Note also these non-fatal warning messages: support.c: In function ‘snapshot_copy’: support.c:316: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result support.c: In function ‘snapshot_append’: support.c:344: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result support.c:346: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result

  What steps will reproduce the problem? - with archfs 0.5.3, run ./compile, using gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu11) What is the expected output? What do you see instead? you see: In function ‘open’, inlined from ‘unzip_revs’ at support.c:74: /usr/include/bits/fcntl2.h:51: error: call to ‘__open_missing_mode’ declared with attribute error: open with O_CREAT in second argument needs 3 arguments Please provide any additional information below. This problem does not seem to occur with earlier versions of gcc. The fix (suggested by Andrew Ferguson) is in layout/support.c at line 74, change: if ((descriptor = open(mirror, O_WRONLY | O_CREAT)) == -1) to: if ((descriptor = open(mirror, O_WRONLY | O_CREAT, 0777)) == -1) Note also these non-fatal warning messages: support.c: In function ‘snapshot_copy’: support.c:316: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result support.c: In function ‘snapshot_append’: support.c:344: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result support.c:346: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result
• Nov 19, 2008

  issue 15 (Cannot view archfs through Samba - directories as zero lengt...) reported by domi...@winkfieldproperties.co.uk   -   What steps will reproduce the problem? 1. create a samba share at the mountpoint for same user as mounted the archfs 2. on another computer on the same network, create a samba share to the archfs mountpoint. Navigate through this into a 'date' directory 3. directories are here listed as zero length files, you cannot navigate into them What is the expected output? What do you see instead? you expect to see directories but instead you see zero length files What version of the product are you using? On what operating system? Ubuntu 8.10 Server, archfs 0.5.3, Samba 3.2.3 Please provide any additional information below. When I am logged in to a shell, archfs does show directories correctly. This problem does not appear with sshfs, so it does not seem to be an issue with fuse.

  What steps will reproduce the problem? 1. create a samba share at the mountpoint for same user as mounted the archfs 2. on another computer on the same network, create a samba share to the archfs mountpoint. Navigate through this into a 'date' directory 3. directories are here listed as zero length files, you cannot navigate into them What is the expected output? What do you see instead? you expect to see directories but instead you see zero length files What version of the product are you using? On what operating system? Ubuntu 8.10 Server, archfs 0.5.3, Samba 3.2.3 Please provide any additional information below. When I am logged in to a shell, archfs does show directories correctly. This problem does not appear with sshfs, so it does not seem to be an issue with fuse.
• Nov 18, 2008

  issue 14 (ArchFS should only extract on demand) commented on by gruszczy   -   I know about this problem, but due to fact I am studying and working at once, I hardly can find any time to sit down and code it. I guess, the first time I am free, will be around the summer - at this time I should finish studying. And then I will happily add this feature.

  I know about this problem, but due to fact I am studying and working at once, I hardly can find any time to sit down and code it. I guess, the first time I am free, will be around the summer - at this time I should finish studying. And then I will happily add this feature.
• Nov 12, 2008

  issue 14 (ArchFS should only extract on demand) reported by matthew....@gatech.edu   -   Due to the design of ArchFS, it is basically impossible for me to use. The reason is that it fills my entire root filesystem before it even finishes initializing (it also doesn't appear to notice this, because it just "continues" in grdiff.c when unzip fails; this is a separate bug.) This is clearly due to it extracting all of the metadata files up front. For me, /each/ of the early metadata files is 190 megabytes extracted. Later, I got more efficient with my excludes, so they became smaller. But in my opinion, archfs shouldn't extract the mirror_metadata until it's needed. There's no reason to extract metadata from 2007 before the filesystem even starts up. What if I only want to browse backups from last month?

  Due to the design of ArchFS, it is basically impossible for me to use. The reason is that it fills my entire root filesystem before it even finishes initializing (it also doesn't appear to notice this, because it just "continues" in grdiff.c when unzip fails; this is a separate bug.) This is clearly due to it extracting all of the metadata files up front. For me, /each/ of the early metadata files is 190 megabytes extracted. Later, I got more efficient with my excludes, so they became smaller. But in my opinion, archfs shouldn't extract the mirror_metadata until it's needed. There's no reason to extract metadata from 2007 before the filesystem even starts up. What if I only want to browse backups from last month?
• Nov 11, 2008

  issue 7 (Only user who has same perms as rdiff-backup user can run ar...) commented on by matthew....@gatech.edu   -   As far as how it actually convinces itself there's an empty repo, I found that the error chain was being lost at initialize. unzip_revs in grdiff.c returns -1 if the directory can't be opened. full_build then returns -1, which is passed on by all_init, but then dropped by initialize! Here's a better patch that adds a bit more debugging in grdiff and error checking in initialize(), as well as the changes in the other patch.

  As far as how it actually convinces itself there's an empty repo, I found that the error chain was being lost at initialize. unzip_revs in grdiff.c returns -1 if the directory can't be opened. full_build then returns -1, which is passed on by all_init, but then dropped by initialize! Here's a better patch that adds a bit more debugging in grdiff and error checking in initialize(), as well as the changes in the other patch.
• Nov 11, 2008

  issue 7 (Only user who has same perms as rdiff-backup user can run ar...) commented on by matthew....@gatech.edu   -   I discovered this issue independently. I run my rdiff-backup backups as root. I got the mysterious empty repository, and eventually traced down the cause. I added an additional check to check_repo that should pick up on this and associated text for the error (EACCES). A patch is attached. Also, I made fail print to standard error (rather than standard output). If you'd like I can attach that as a separate patch.

  I discovered this issue independently. I run my rdiff-backup backups as root. I got the mysterious empty repository, and eventually traced down the cause. I added an additional check to check_repo that should pick up on this and associated text for the error (EACCES). A patch is attached. Also, I made fail print to standard error (rather than standard output). If you'd like I can attach that as a separate patch.
• Oct 04, 2008

  issue 13 (Invalid configuration / machine not recognized) reported by nicos.frey   -   What steps will reproduce the problem? 1. go in Centos 5.1, updated via yum 2. go in archfs 3. type ./configure What is the expected output? What do you see instead? No idea of expected output. But know that this one is not the right one : checking build system type... Invalid configuration `x86_64-unknown-linux-': machine `x86_64-unknown-linux' not recognized configure: error: /bin/sh ./config.sub x86_64-unknown-linux- failed What version of the product are you using? On what operating system? used archfs-0.5.3 Please provide any additional information below. I am very interested by the archfs idea. I would like to participate to porting it to Centos/64 bits architecture. Nicolas

  What steps will reproduce the problem? 1. go in Centos 5.1, updated via yum 2. go in archfs 3. type ./configure What is the expected output? What do you see instead? No idea of expected output. But know that this one is not the right one : checking build system type... Invalid configuration `x86_64-unknown-linux-': machine `x86_64-unknown-linux' not recognized configure: error: /bin/sh ./config.sub x86_64-unknown-linux- failed What version of the product are you using? On what operating system? used archfs-0.5.3 Please provide any additional information below. I am very interested by the archfs idea. I would like to participate to porting it to Centos/64 bits architecture. Nicolas
• Sep 23, 2008

  issue 11 (make wants -D_FILE_OFFSET_BITS=64) commented on by SanskritFritz   -   Confirmed, the program compiles well, and I can use it with my backup repository. Thank you!

  Confirmed, the program compiles well, and I can use it with my backup repository. Thank you!
• Sep 23, 2008

  issue 12 (fuse: fork() failed: Cannot allocate memory) reported by newsgroups@runout.at   -   What version of the product are you using? On what operating system? 0.5.2 (claims to be 0.5.1) ubuntu hardy 8.04, 64bit dual core 2.5GHz, 4GB RAM, 5.7GB Swap Please provide any additional information below. after the machine is using around 6GB memory (RAM+Swap) i get following error (2x): fuse: fork() failed: Cannot allocate memory i have a fuse-sshfs mount of my server1 (/mnt/sshfs-server1/) on that server1 is the rdiff-backup at /mnt/backup/ninja/server1 this i want to mount with archfs to the mountpoint /mnt/archfs-backup/ with the following command: m@xi:$ archfs /mnt/archfs-backup/ /mnt/sshfs-server1/mnt/backup/ninja/ server1 fuse: fork() failed: Cannot allocate memory fuse: fork() failed: Cannot allocate memory m@xi:$ the repository is 3.2GB m@server1:~$ du -hsc /mnt/backup/ninja/server1/rdiff-backup-data/ 3.2G /mnt/backup/ninja/server1/rdiff-backup-data/ 3.2G total to create the backups i use backupninja which uses rdiff-backup. permissions are a problem because ninja runs as root and i can not ssh as root to the server1. so i have to chown the repository to my user before i can use archfs. maybe that issue is backupninja related. markus

  What version of the product are you using? On what operating system? 0.5.2 (claims to be 0.5.1) ubuntu hardy 8.04, 64bit dual core 2.5GHz, 4GB RAM, 5.7GB Swap Please provide any additional information below. after the machine is using around 6GB memory (RAM+Swap) i get following error (2x): fuse: fork() failed: Cannot allocate memory i have a fuse-sshfs mount of my server1 (/mnt/sshfs-server1/) on that server1 is the rdiff-backup at /mnt/backup/ninja/server1 this i want to mount with archfs to the mountpoint /mnt/archfs-backup/ with the following command: m@xi:$ archfs /mnt/archfs-backup/ /mnt/sshfs-server1/mnt/backup/ninja/ server1 fuse: fork() failed: Cannot allocate memory fuse: fork() failed: Cannot allocate memory m@xi:$ the repository is 3.2GB m@server1:~$ du -hsc /mnt/backup/ninja/server1/rdiff-backup-data/ 3.2G /mnt/backup/ninja/server1/rdiff-backup-data/ 3.2G total to create the backups i use backupninja which uses rdiff-backup. permissions are a problem because ninja runs as root and i can not ssh as root to the server1. so i have to chown the repository to my user before i can use archfs. maybe that issue is backupninja related. markus
• Sep 22, 2008

  issue 1 (Core dumped) Status changed by artoole   -   No news for long time - assume unreproducible :)

  Status: Invalid

  No news for long time - assume unreproducible :)

  Status: Invalid
• Sep 22, 2008

  issue 11 (make wants -D_FILE_OFFSET_BITS=64) changed by artoole   -   Fixed in download section (archfs-0.5.2.tar.gz) - code in SVN is different, so not fixed there.

  Status: Fixed

  Owner: artoole

  Fixed in download section (archfs-0.5.2.tar.gz) - code in SVN is different, so not fixed there.

  Status: Fixed

  Owner: artoole
• Sep 04, 2008

  issue 11 (make wants -D_FILE_OFFSET_BITS=64) reported by SanskritFritz   -   What steps will reproduce the problem? 1. ./configure 2. make frank@HomeC:~/Programs/ArchFS/Stable$ make make all-recursive make[1]: Entering directory `/home/frank/Programs/ArchFS/Stable' Making all in layout make[2]: Entering directory `/home/frank/Programs/ArchFS/Stable/layout' gcc -DHAVE_CONFIG_H -I. -I.. -Wall -O3 -D_GNU_SOURCE -MT core.o -MD -MP -MF .deps/core.Tpo -c -o core.o core.c In file included from /usr/include/fuse/fuse.h:26, from /usr/include/fuse.h:9, from ../headers.h:21, from core.h:4, from core.c:1: /usr/include/fuse/fuse_common.h:32:2: error: #error Please add -D_FILE_OFFSET_BITS=64 to your compile flags! make[2]: *** [core.o] Error 1 make[2]: Leaving directory `/home/frank/Programs/ArchFS/Stable/layout' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/frank/Programs/ArchFS/Stable' make: *** [all] Error 2 Kubuntu Hardy 32bit, with dual core processor. Where should I put this flag? What is the reason i cannot compile? Sincerelly Frank

  What steps will reproduce the problem? 1. ./configure 2. make frank@HomeC:~/Programs/ArchFS/Stable$ make make all-recursive make[1]: Entering directory `/home/frank/Programs/ArchFS/Stable' Making all in layout make[2]: Entering directory `/home/frank/Programs/ArchFS/Stable/layout' gcc -DHAVE_CONFIG_H -I. -I.. -Wall -O3 -D_GNU_SOURCE -MT core.o -MD -MP -MF .deps/core.Tpo -c -o core.o core.c In file included from /usr/include/fuse/fuse.h:26, from /usr/include/fuse.h:9, from ../headers.h:21, from core.h:4, from core.c:1: /usr/include/fuse/fuse_common.h:32:2: error: #error Please add -D_FILE_OFFSET_BITS=64 to your compile flags! make[2]: *** [core.o] Error 1 make[2]: Leaving directory `/home/frank/Programs/ArchFS/Stable/layout' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/frank/Programs/ArchFS/Stable' make: *** [all] Error 2 Kubuntu Hardy 32bit, with dual core processor. Where should I put this flag? What is the reason i cannot compile? Sincerelly Frank
• Aug 23, 2008

  issue 10 (Fail to access the mountpoint by another user) commented on by freecityhk   -   http://fuse.sourceforge.net/wiki/index.php/FAQ#Why_donx27.t_other_users_have_access_to_the_mounted_filesystemx3f.

  http://fuse.sourceforge.net/wiki/index.php/FAQ#Why_donx27.t_other_users_have_access_to_the_mounted_filesystemx3f.