Downloaded from here
Untarred, mkdir build, mkdir PC, executed...
../../gdb/configure --target=arm-linux-gnueabihf
returned...
../../gdb/gdbsupport/common-defs.h:33:10: fatal error: ../../gnulib/config.h: No such file or directory
#include "../../gnulib/config.h"
There was a 'gnulib' package I could install, installed it and it made no difference
Edited ../../gdb/gdbsupport/common-defs.h and found one header include based on gdbserver/gdb.
#ifdef GDBSERVER
#include "build-gnulib-gdbserver/config.h"
#else
#include "../../gnulib/config.h"
#endif
Go back two levels and there is a gnulib directory but no config.h, ll shows
-rw-rw-r-- 1 user user 51507 May 23 15:10 aclocal.m4
-rw-rw-r-- 1 user user 2417 May 23 15:10 ChangeLog
-rw-rw-r-- 1 user user 69989 May 23 15:10 config.in
-rw-rw-r-- 1 user user 743485 May 23 15:10 configure
-rw-rw-r-- 1 user user 1625 Feb 8 05:49 configure.ac
drwxrwxr-x 5 user user 4096 Jun 2 14:53 import/
-rw-rw-r-- 1 user user 739 May 23 15:10 Makefile.am
-rw-rw-r-- 1 user user 58332 May 23 15:10 Makefile.in
drwxrwxr-x 2 user user 4096 Jun 2 14:53 patches/
-rw-rw-r-- 1 user user 249 Sep 20 2019 README
-rwxrwxr-x 1 user user 5641 May 23 15:10 update-gnulib.sh
So in the process of writing out the end of my question I put two and two together and am just answering so no one else has to go through this.
As you'll notice configure in gnulib is not executable, so first I ran 'chmod +x configure' Before running it I figured I would go back into my build/PC directory to run configure from there to see if that would recursively configure gnulib, but that did not seem to be the case. You will need to execute ./configure inside of the gnulib directory to generate the config.h. I think regardless of you cross compiling or not you want gnulib to NOT have an explicit target, looks like it'll be used solely for the purpose of building GDB.
After running ./configure you'll now notice you have a config.h, yeahhhhhhh! Now go back to your build/PC directory and run make. Guess what? It will now complain about having already configured the gnulib directory and you need to clean up for make to work. "But Joe!", you say, "Won't that remove the config.h we so desperately needed?" "Yes! Yes it will!" So you need to move your config.h elsewhere, execute 'make distclean' inside of the gnulib directory, go back to your build directory, just wipe it out completely because you'll have issues due to the mixed configurations, re-configure yet again, DON'T FORGET TO COPY CONFIG.H BACK INTO GNULIB/, then run make.
All in a days work.
Related
I am trying to create a build system, but the structure I am supposed to use in unclear.
I've got various library files with their associated includes.
These library files (or modules) may have various versions. So, module1 may have only 1 version, but ModuleN may have 50 versions.
Now my problem is that I am not sure how to organize my tree so that I can build my Library.a package for a given version.
My first thought was to organize my files in the following way:
Libraries Includes
¦ ¦
---------------------- ----------------------
¦ ¦ ¦ ¦ ¦ ¦
V1.0 V1.1 V1.2 V1.0 V1.1 V1.2
¦ ¦ ¦ ¦ ¦ ¦
Lib1.c Lib3.c Lib2.c Lib1.h Lib3.h Lib2.h
Lib2.c Lib3.c Lib2.h Lib3.h
Lib3.c Lib3.h
Lib4.c Lib4.h
Now, how would I build my package V1.2, considering it also needs to incorporate the Union of the latest libraries across the entire tree (ie. V1.2 package = V1.0 U V1.1 U V1.2). In this case, it would not be too difficult to define the rules manually, but it will quickly become unmanageable with 100`s of files.
Maybe duplicating unchanged files from a version to the next one in common practice, but it then becomes difficult to know where is what.
Is there a typical approach to this problem?
The proper way to handle this is with a version control system like Git. It was designed to handle exactly what you're describing.
There were several suggestions in the comments regarding the use of Git to accomplish what you want. However, you seem to have a misunderstanding of how exactly the files in your library would be stored.
You said in the comments:
I would like to build any version of the library out of the latest repository (pulled freshly from Git if you like), in one go, without having to do potentially 100's of pulls from Git
And:
But if you understood branches, you would know that by switching you will loose your previous snapshot. So if you start by building a branch (get V1.0), then switch to second branch to build V1.1, you will have lost V1.0.
Looking at these comments and your sample file structure, this suggests that you think the V1.0 branch would contain Lib1.c, Lib2.c, Lib3.c, and Lib4.c while the V1.1 branch would only contain Lib3.c and that the V1.2 branch would only contain Lib2.c and Lib3.c. That is not how Git works.
Here is an example of how you would store these files in Git:
Start by putting the V1.0 files into a directory structure:
[dbush#db-centos7 mylib]$ ls -lR
.:
total 0
drwxrwxr-x. 2 dbush dbush 62 Jan 20 10:19 inc
drwxrwxr-x. 2 dbush dbush 62 Jan 20 10:17 src
./inc:
total 16
-rw-rw-r--. 1 dbush dbush 13 Jan 20 10:18 Lib1.h
-rw-rw-r--. 1 dbush dbush 13 Jan 20 10:19 Lib2.h
-rw-rw-r--. 1 dbush dbush 13 Jan 20 10:18 Lib3.h
-rw-rw-r--. 1 dbush dbush 13 Jan 20 10:19 Lib4.h
./src:
total 16
-rw-rw-r--. 1 dbush dbush 62 Jan 20 10:16 Lib1.c
-rw-rw-r--. 1 dbush dbush 62 Jan 20 10:17 Lib2.c
-rw-rw-r--. 1 dbush dbush 62 Jan 20 10:17 Lib3.c
-rw-rw-r--. 1 dbush dbush 62 Jan 20 10:17 Lib4.c
Then create a new git repo, add the files, and commit them:
[dbush#db-centos7 mylib]$ git init
Initialized empty Git repository in /home/dbush/mylib/.git/
[dbush#db-centos7 mylib]$ git add *
[dbush#db-centos7 mylib]$ git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
# (use "git rm --cached <file>..." to unstage)
#
# new file: inc/Lib1.h
# new file: inc/Lib2.h
# new file: inc/Lib3.h
# new file: inc/Lib4.h
# new file: src/Lib1.c
# new file: src/Lib2.c
# new file: src/Lib3.c
# new file: src/Lib4.c
#
[dbush#db-centos7 mylib]$ git commit
Now you have the version 1.0 files committed, so next we create a tag based on the current version:
[dbush#db-centos7 mylib]$ git tag -a -m "version 1.0" V1.0
[dbush#db-centos7 mylib]$ git tag -l
V1.0
Right now, Lib3.c looks like this:
#include <stdio.h>
void lib3()
{
printf("lib3 1.0\n");
}
Now let's make a change for the 1.1 version:
#include <stdio.h>
void lib3()
{
printf("lib3 1.1\n");
}
We can see there's a difference between the working copy and the checked in version:
[dbush#db-centos7 mylib]$ git status
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: src/Lib3.c
#
no changes added to commit (use "git add" and/or "git commit -a")
[dbush#db-centos7 mylib]$ git diff
diff --git a/src/Lib3.c b/src/Lib3.c
index 3593018..12542d9 100644
--- a/src/Lib3.c
+++ b/src/Lib3.c
## -2,5 +2,5 ##
void lib3()
{
- printf("lib3 1.0\n");
+ printf("lib3 1.1\n");
}
Then we commit the change:
[dbush#db-centos7 mylib]$ git add src/Lib3.c
[dbush#db-centos7 mylib]$ git commit -m "updated Lib3.c for version 1.1"
And tag it as version 1.1:
[dbush#db-centos7 mylib]$ git tag -a -m "version 1.1" V1.1
Now let's suppose we want to get the 1.0 code to build. We checkout the tag:
[dbush#db-centos7 mylib]$ git checkout V1.0
Note: checking out 'V1.0'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
git checkout -b new_branch_name
HEAD is now at a1ee8c1... initial commit
[dbush#db-centos7 mylib]$ ls -lR
.:
total 0
drwxrwxr-x. 2 dbush dbush 62 Jan 20 10:19 inc
drwxrwxr-x. 2 dbush dbush 62 Jan 20 10:33 src
./inc:
total 16
-rw-rw-r--. 1 dbush dbush 13 Jan 20 10:18 Lib1.h
-rw-rw-r--. 1 dbush dbush 13 Jan 20 10:19 Lib2.h
-rw-rw-r--. 1 dbush dbush 13 Jan 20 10:18 Lib3.h
-rw-rw-r--. 1 dbush dbush 13 Jan 20 10:19 Lib4.h
./src:
total 16
-rw-rw-r--. 1 dbush dbush 62 Jan 20 10:16 Lib1.c
-rw-rw-r--. 1 dbush dbush 62 Jan 20 10:17 Lib2.c
-rw-rw-r--. 1 dbush dbush 62 Jan 20 10:33 Lib3.c
-rw-rw-r--. 1 dbush dbush 62 Jan 20 10:17 Lib4.c
[dbush#db-centos7 mylib]$ cat src/Lib3.c
#include <stdio.h>
void lib3()
{
printf("lib3 1.0\n");
}
[dbush#db-centos7 mylib]$ cat src/Lib2.c
#include <stdio.h>
void lib2()
{
printf("lib2 1.0\n");
}
You can see that the full source tree is available and that Lib3.c is the 1.0 version, as is Lib2.c. Now we want to build 1.1, so let's get the 1.1 tag:
[dbush#db-centos7 mylib]$ git checkout V1.1
Previous HEAD position was a1ee8c1... initial commit
HEAD is now at 95a429c... updated Lib3.c for version 1.1
[dbush#db-centos7 mylib]$ ls -lR
.:
total 0
drwxrwxr-x. 2 dbush dbush 62 Jan 20 10:19 inc
drwxrwxr-x. 2 dbush dbush 62 Jan 20 10:35 src
./inc:
total 16
-rw-rw-r--. 1 dbush dbush 13 Jan 20 10:18 Lib1.h
-rw-rw-r--. 1 dbush dbush 13 Jan 20 10:19 Lib2.h
-rw-rw-r--. 1 dbush dbush 13 Jan 20 10:18 Lib3.h
-rw-rw-r--. 1 dbush dbush 13 Jan 20 10:19 Lib4.h
./src:
total 16
-rw-rw-r--. 1 dbush dbush 62 Jan 20 10:16 Lib1.c
-rw-rw-r--. 1 dbush dbush 62 Jan 20 10:17 Lib2.c
-rw-rw-r--. 1 dbush dbush 62 Jan 20 10:35 Lib3.c
-rw-rw-r--. 1 dbush dbush 62 Jan 20 10:17 Lib4.c
[dbush#db-centos7 mylib]$ cat src/Lib3.c
#include <stdio.h>
void lib3()
{
printf("lib3 1.1\n");
}
[dbush#db-centos7 mylib]$ cat src/Lib2.c
#include <stdio.h>
void lib2()
{
printf("lib2 1.0\n");
}
You can see from here that not only is the 1.1 copy of Lib3.c present but also all other files with their V1.0 content. You don't need to do multiple checkouts and you don't lose any files that weren't updated in the latest commit.
You can follow the above example to set up your repo. So you would:
Get the 1.0 files together in the desired directory structure
Create a new git repo and commit the files
Tag version 1.0
Copy in the files changes for version 1.1
Commit the changed files then tag version 1.1
Copy in the files changes for version 1.2
Commit the changed files then tag version 1.2
Etc...
This also works if you need to delete a file when going to a new version. So for example if in version 1.3 you remove Lib4.c, then you'll see the file when you check out tags 1.0, 1.1, and 1.2, but not when you check out tag 1.3.
So once you have your Git repo set up, all you need to do is checkout a single tag once and you have everything you need.
EDIT:
When it comes time use these files for multiple (possibly concurrent) builds, Git is still a good fit for this. If you were to keep your proposed folder structure, you would need to know the full history of the files to get the proper versions of each, and you would still want to make a copy of each relevant source file into you "active" build directory so that object files created by one build aren't overwritten by another. Git will fully manage all of this for you.
Git allows for cloning a local repository, and for performing a minimal clone of a particular branch or tag, that way you only copy what you need and don't grab the entire git history in the processes, so having multiple copies isn't an issue. You can do this as follows:
[dbush#db-centos7 mylib]$ git status
# On branch master
nothing to commit, working directory clean
[dbush#db-centos7 mylib]$ cd ..
[dbush#db-centos7 ~]$ git clone --single-branch --branch V1.0 ./mylib mylib-v1.0
Cloning into 'mylib-v1.0'...
done.
Note: checking out 'a1ee8c1bfdbb20f3e0716212582338371b60d9bc'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
git checkout -b new_branch_name
[dbush#db-centos7 ~]$ cd mylib-v1.0
[dbush#db-centos7 mylib-v1.0]$ git status
# Not currently on any branch.
nothing to commit, working directory clean
[dbush#db-centos7 mylib-v1.0]$ git branch -l
* (no branch)
[dbush#db-centos7 mylib-v1.0]$
The --branch option says to clone a specific branch or tag, while the --single-branch option creates a shallow clone containing just the given tag so that the .git directory of the clone isn't huge and can be created quickly.
I know that OP said he did not want to use Git, so this answer is more for other people who reads this question.
A very common practice to build an arbitrary version from a repository is to use tags. Tagging is a way to highlight a specific commit. Git supports two types of tags: lightweight and annotated.
Lightweight tags is like a branch. It is just a pointer to a commit. The difference from a branch is that this pointer does not change with new commits. These tags are not recommended for your purpose. They are more for developers during developing. To create a lightweight tag, use this command
git tag <name>
The other tag type is annotated tags. They contain much more information and are checksummed. These are the ones you want to use for releases. As with commits, you specify a tag message for annotated tags. To create an annotated tag, use this command:
git tag -a <name>
This will open up an editor where you write a tag message. You can specify a message on command line too with -m "<message>"
To view all tags, just use:
git tag
You can checkout tags the same way you checkout branches:
git checkout <tag>
Read more about tagging here: https://git-scm.com/book/en/v2/Git-Basics-Tagging
So what you do is that you create a (preferably annotated) tag for each commit that corresponds to a release. Then, assuming you can build the project by just invoking make you can build any version with these two commands:
git checkout <tag>
make
Note: In the comments above, I was talking about branches. That was temporary confusion on my behalf. It is possible to use branches for this purpose, but tagging is the proper method.
I have this C program:
#include <sys/stat.h>
#include <stdlib.h>
int main(void) {
if (chmod("/tmp/foo", 0755 | S_ISGID) < 0) {
exit(1);
}
exit(0);
}
When I run it like this:
rm -f /tmp/foo &&
touch /tmp/foo &&
./a.out &&
ls -al /tmp/foo &&
a.out runs with exit code 0 but the output is:
-rwxr-xr-x 1 philipp wheel 0 Mar 16 06:58 /tmp/foo
Why is the groupid flag not set here? The permissions should be -rwxr-sr-x.
The following things would fix the issue (but I still wonder why I see this effect):
running the program as root
running it in a different directory
running it on Linux
setting the set-user-id (S_ISUID)
I can swear it worked in an earlier version of OSX
What I tried but didn't work:
chmod g+s /tmp/foo also doesn't work
disabling csrutil did not change anything
altering the permissions on /tmp/ to something different, e.g. 0777 or 4777
So the question remains: what does make /tmp/ different from the other directories if it's not the permissions? The only difference I could see is:
ls -al /
showed tmp as this:
lrwxr-xr-x# 1 root wheel 11 Dec 11 19:28 tmp -> private/tmp
The # sign at the end shows that there are some non-unix properties set on the directory. Querying those with ls -l# /tmp shows:
lrwxr-xr-x# 1 root wheel 11 Dec 11 19:28 /tmp -> private/tmp
com.apple.FinderInfo 32
com.apple.rootless 0
Update: According to comment feedbacks and a downvote I figured the question is confusing, so I totally revised the question and the title. During revision I found out that I wrongly compared the effects of my program against chmod u+s which was wrong, I need to compare against chmod g+s, I also corrected this in my question.
The chmod() system call sets the permissions on a file to only the value you provide. This means that setting permissions to S_IRUSR | S_ISGID clears all other permissions, including user write and execute.
What you probably want is:
chmod("/tmp/foo", 0755 | S_ISGID);
(0755 being the octal mode for user read+write+execute and group/other read+execute -- it's a lot less typing than the equivalent constants.)
I try to get the name of the folder / file pointed by the symbolic link.
For example, when you do ls -l
You can get this result
-rw-r--r-- 1 macos staff 0 Feb 22 12:05 test
lrwxr-xr-x 1 macos staff 7 Feb 19 11:05 sl -> test
How could I do, if I know the path of sl to get the file/folder here it pointed to ?
I want to do it using stat if possible.
Any suggestion ?
So to summarize :
It's impossible to get the name of the file/folder pointed by a symbolic link, using lstat or stat.
The function readlink can do the job => Man : http://man7.org/linux/man-pages/man2/readlink.2.html. You will get example in the man
Thank you for helping me solve my problem
Nagiosql generated files make problems during preflight check - but everythings seems to be okay.
/etc/nagios/nagios.cfg
....
## Hosts
cfg_dir=/etc/nagiosql/hosts/
cfg_file=/etc/nagiosql/hosttemplates.cfg
cfg_file=/etc/nagiosql/hostgroups.cfg
cfg_file=/etc/nagiosql/hostextinfo.cfg
cfg_file=/etc/nagiosql/hostescalations.cfg
cfg_file=/etc/nagiosql/hostdependencies.cfg
## Services
cfg_dir=/etc/nagiosql/services/
cfg_file=/etc/nagiosql/servicetemplates.cfg
cfg_file=/etc/nagiosql/servicegroups.cfg
cfg_file=/etc/nagiosql/serviceextinfo.cfg
cfg_file=/etc/nagiosql/serviceescalations.cfg
cfg_file=/etc/nagiosql/servicedependencies.cfg
...
nagios -v /etc/nagios/nagios.cfg
....
Running pre-flight check on configuration data...
Checking services...
Error: There are no services defined!
Checked 0 services.
Checking hosts...
Error: There are no hosts defined!
Checked 0 hosts.
The content seems okay to me
[root#xxx services]# cd /etc/nagiosql/services/
[root#xxx services]# ls -alh
total 20K
drwsr-sr-x 2 apache nagios 4.0K Aug 7 10:46 .
drwsr-sr-x 5 apache nagios 4.0K Aug 7 12:17 ..
-rw-r--r-- 1 apache nagios 2.3K Aug 7 10:46 localhost.cfg
-rw-r--r-- 1 apache nagios 2.2K Aug 7 10:46 www.google.com.cfg
-rw-r--r-- 1 apache nagios 1.1K Aug 7 10:46 www.yahoo.com.cfg
[root#xxx hosts]# ls -alh
total 16K
drwsr-sr-x 2 apache nagios 4.0K Aug 11 07:12 .
drwsr-sr-x 5 apache nagios 4.0K Aug 7 12:17 ..
-rw-r--r-- 1 apache nagios 800 Aug 11 07:12 GIT.cfg
-rw-r--r-- 1 apache nagios 948 Aug 11 07:12 psm01.cfg
Content also seems to be fine (generated by nagiosql):
[root#xxx hosts]# vi GIT.cfg
###############################################################################
#
# Host configuration file
#
# Created by: Nagios QL Version 3.2.0
# Date: 2015-08-11 07:12:54
# Version: Nagios 3.x config file
#
# --- DO NOT EDIT THIS FILE BY HAND ---
# Nagios QL will overwite all manual settings during the next update
#
###############################################################################
define host {
host_name GIT
alias GIT Server
address 172.25.10.80
register 0
}
###############################################################################
#
# Host configuration file
#
# END OF FILE
#
###############################################################################
~
Can somebody tell me where the solution for this problem is? Already wasted 2 hours...
Try removing the final slash from the directory names in your cfg_dir definitions and see if that doesn´t get it to recognize the cfg files in that directory.
For example,
Change:
cfg_dir=/etc/nagiosql/hosts/
...
cfg_dir=/etc/nagiosql/services/
To:
cfg_dir=/etc/nagiosql/hosts
...
cfg_dir=/etc/nagiosql/services
EDIT:
Okay I think directory permissions may be causing the cfg_dir evaulations to fail. According to the ls -alh output you listed, your /etc/nagiosql/hosts/, /etc/nagiosql/services/, and /etc/nagiosql/ directories do not grant write permissions to the nagios group. Nagios will need to get a directory listing for those directories and will need group write permissions to do it.
To remedy:
chmod g+w /etc/nagiosql/hosts/
chmod g+w /etc/nagiosql/services/
Restart nagios service.
Also, you don't need to remove the slashes from the directory paths in the nagios cfg_dir configurations. Nagios will strip the trailing slash (/) for you, according to the code:
https://github.com/NagiosEnterprises/nagioscore/blob/eb8e83d5d05e572eb8c0d4d4764885c5427b4b69/xdata/xodtemplate.c#L327
/* process all files in a config directory */ else if(!strcmp(var, "xodtemplate_config_dir") || !strcmp(var, "cfg_dir")) {
if(config_base_dir != NULL && val[0] != '/') {
asprintf(&cfgfile, "%s/%s", config_base_dir, val);
} else
cfgfile = strdup(val);
/* strip trailing / if necessary */ if(cfgfile != NULL && cfgfile[strlen(cfgfile) - 1] == '/')
cfgfile[strlen(cfgfile) - 1] = '\x0';
/* process the config directory... */ result = xodtemplate_process_config_dir(cfgfile, options);
my_free(cfgfile);
/* if there was an error processing the config file, break out of loop */ if(result == ERROR)
break; } }
EDIT #2: In the host definition you posted, your register value is set to 0. Try setting it to 1 instead. register 0 is used for templates that will be inherited from, but will not actually show up in the Nagios UI.
Change:
define host {
host_name GIT
alias GIT Server
address 172.25.10.80
register 0
}
To:
define host {
host_name GIT
alias GIT Server
address 172.25.10.80
register 1
}
Also please set register 1 for your service definitions as well.
Try adding executable permissions to your directories. Some programs and languages require +x permissions in order to actually open the directory.
If that doesn't work, temporarily set everything to 0777 permissions to see if the issue is permissions related at all.
You also have config problems even if you get that part working. Your host and service configs don't have a use directive in them, which points to a template that would have most of the default values. The register directive is implied as 1 unless you specifically set it to 0 for a template. See the object definitions docs if you need a reference: https://assets.nagios.com/downloads/nagioscore/docs/nagioscore/3/en/objectdefinitions.html
Hi i want to install MinorFS 0.3.5 to my computer. My Ubuntu version is 14.04 LTS. But i had some problems while installing the program.
Firstly i installed all fuse modules and gcc and run the script install.pl.
The program is designed for Ubuntu 8. As a result it wants to install fuse module to start the script install.pl.
But there is not a loadable fuse module for Ubuntu 14.04 LTS. I research about it and i see that, for the latest version of Ubuntu, the kernel is configured to include FUSE instead of compiling it as a module. So, i modified the perl code in install.pl and
install the script.(I install fuseiso with command apt-get install fuseiso just in case.)
Everyting is great for the moment. But for the next step, i run the command on terminal "/etc/init.d/minorfs start ".
And i get this error : " The path specified in /var/minorfs/viewfs.startcap is not a valid base dir for minorviewfs
"
This command runs the minorcapfs and minorviewfs i guess.Minorcapfs run succesfully but for minorviewfs i got this error.
The code which gives the Error writen below:(in minorviewfs file)
unless (-d $basepath) {
print STDERR "The path specified in $VARDIR/viewfs.startcap is not a valid base dir for minorviewfs\n";
exit 1;
}
Then for test, i print my " $basepath " and it's : /mnt/minorfs/cap/61ce0488ac06eba530e178a0d1716ec576b47f71
I couldn't solve this error.
Please help me to get rid of this problem.
Thank you!
I solved the problem with manually making a directory with the mkdir command. Now the script work. But now I have a different problem. The output is ;
Starting MinorFs filesystems minorcapfs going into background, consult syslog for information minorviewfs going into background, consult syslog for information.
Then when i run the command ls -la /mnt/minorfs/priv
i should get a links to the folders. But I have nothing.
dr-xr-xr-x 1 root root 0 Jan 1 1970 .
lrwxrwxrwx 1 root root 0 Jan 1 1970 home ->
lrwxrwxrwx 1 root root 0 Jan 1 1970 tmp ->
So i looked the system log file with gedit /var/log/syslog and i see that Error;
Sep 1 13:51:37 burak-UX31A minorcapfs[3581]: Problem in Fuse::main at /usr/local/bin/minorcapfs line 340
Sep 1 13:51:37 burak-UX31A minorcapfs[3581]: user: 0 1001 ; group 104 104 104 104 at /usr/local/bin/minorcapfs line 341
Sep 1 13:51:37 burak-UX31A minorcapfs[3581]: Probably a problem accesing /dev/fuse at /usr/local/bin/minorcapfs line 342
Sep 1 13:52:01 burak-UX31A minorviewfs[3584]: Use of uninitialized value in subroutine entry at /usr/lib/perl5/Fuse.pm line 147, line 26.
And this the MinorCapfs code ; http://codepad.org/nUUJ3b5m
How to get rid of this problems? Thank you.