Hi all,
I sometimes find an application that includes a 'File manager element', but only allows one to search in the current root menu.
An example is XFburn, there are many others.

Editing fstab to include all possible destinations has made little difference, i am still having to 'import' a file to the current location in order to utilise the app, is there a way around this feature?

I use the FXBurn as an example only,it being my current concern.
This restriction has appeared in other apps in the past though so i would dearly like to learn of a general method to deal with it;is this possible or am i wasting my time looking?

J.

TBH, I don't understand what you are asking. Can you be a bit more detailed?

I think(?) that what you are asking is how to call a prog from anywhere, regardless of where you are on the disk ie your current dir.
If you are working at the cmd line, you can use an absolute path eg

/path/to/program

If you want to just call it by name, even from the GUI, you need to add the dir to your $PATH env variable. You'll need to edit your .bashrc or .bash_profile file in your home dir like this

PATH=$PATH:/path/to/program
export PATH

Then logout and back in.

Hi Chris,

Sorry for the confusion.
I nearly always work from gui, and rarely use the command line.

It's really a browsing problem, i tend to hold stuff on a number of partitions,eg a separate "Backup" partition.
This does not show up in the gui (XFBurn), just the root directory. So if i need to burn something from the backup partition
i currently have to transfer or copy the file into something like the /home/desktop before the app, Xfburn in this example, will show
it.

Using the separate partitions allows me to place stuff there irrespective of which distro i happen to be using at the time, which i find useful
and would like to continue, specially if i happen to be going through a distro-hopping phase.

The "Path" command would be useful if i knew where the particular file resides, but, because of the way i work, this is a rare thing.

If you could imagine that your file manager would only access the root directory of the app, then transfer that behaviour to the app you wanted to use
where system browsing was either desirable or neccessary then you have the nubb of the problem.

It may be this is application-specific behaviour, in which case i shall have to live with it, but i wonder if there is a generic solution that could be applied to any instance where it occurs?

I hope this explains it better.
J.

That is much clearer (to me anyway). Definitely sounds like your /etc/fstab is messed up. If you don't mind a little cmd line stuff, the output of the following cmds would help

cat /etc/fstab

fdisk -l

(that's a lower case L)

both cmds need to be run as root. I'm afraid I don't know how to get that from the GUI; I just jump into an xterm/terminal window for that level of detail.

hi Chris,

[root@localhost jankers]# cat /etc/fstab
# Entry for /dev/hdb5 :
UUID=89498577-e85c-48e5-95ca-f968ade4cc9d / ext3 defaults 1 1
none /proc proc defaults 0 0
# Entry for /dev/hda7 :
UUID=bd2af2ed-65c9-4ef5-6179-c2edc3d4b9a1 /tmp ext3 defaults 1 2
# Entry for /dev/hdb7 :
UUID=12decb01-2462-484b-b0f6-011dd476736b swap swap defaults 0 0
none /dev/pts devpts mode=0620 0 0
# /dev/hda1, size=62910477, type=12: Win98 FAT32, LBA-mapped (primary)
/dev/hda1 /mnt/win_c vfat user,exec,rw,noauto,iocharset=utf8,umask=000 0 0

# /dev/hda5, size=10490382, type=11: FAT32 (extended)
/dev/hda5 /mnt/win_d vfat user,exec,rw,noauto,iocharset=utf8,umask=000
# /dev/hdb1, size=41945652, type=131: Journalised FS: ext3 (primary)
/dev/hdb1 /mnt/hdb1 ext3 user,exec,rw,noauto 0 0
--------------------------------------------------

[root@localhost jankers]# fdisk -l

Disk /dev/hda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x8601d785

Device Boot Start End Blocks Id System
/dev/hda1 * 1 3916 31455238+ c W95 FAT32 (LBA)
/dev/hda2 3917 9729 46692922+ f W95 Ext'd (LBA)
/dev/hda5 3917 4569 5245191 b W95 FAT32
/dev/hda6 4570 6357 14362078+ 83 Linux
/dev/hda7 7834 9729 15229588+ 83 Linux
/dev/hda8 6358 7833 11855938+ 83 Linux

Partition table entries are not in disk order

Disk /dev/hdb: 82.0 GB, 81964302336 bytes
255 heads, 63 sectors/track, 9964 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x060a0609

Device Boot Start End Blocks Id System
/dev/hdb1 * 1 2611 20972826 83 Linux
/dev/hdb2 2612 9964 59062972+ 5 Extended
/dev/hdb5 2612 5222 20972826 83 Linux
/dev/hdb6 5223 9835 37053891 83 Linux
/dev/hdb7 9836 9964 1036161 82 Linux swap / Solaris
[

J.

Humm, i'm beginning to think this may be something to do with that particular application.

I have loaded Xfburn into a separate distro, which does have a complete fstab listing of all devices, and the same behaviour is present.

I then tried to read the file for clues but it is a Bin file and beyond me as i don't read hex and do not know how to list such files
in readable English.

J.