mirror of
https://github.com/EGroupware/egroupware.git
synced 2024-11-07 16:44:20 +01:00
removed outdated docu
This commit is contained in:
Ralf Becker
parent
dc12a69e9a
commit
a05b0f0fa1
@ -1,6 +0,0 @@
|
|||||||
|
|
||||||
We plan to organize documents centralized on wiki site, for easy maintain. For the latest documents, please visite the public wiki http://egroupware.org/wiki/
|
|
||||||
|
|
||||||
The documents currently in this directory will most likely be moved to wiki upon next update, and please developers don't store more documents here.
|
|
||||||
|
|
||||||
--- message drop by zhangweiwu@realss.com
|
|
||||||
@ -1,109 +0,0 @@
|
|||||||
// There is a accounts_shared which added functions that are identical for all
|
|
||||||
|
|
||||||
class accounts_{
|
|
||||||
var $db;
|
|
||||||
var $account_id;
|
|
||||||
var $data;
|
|
||||||
var $memberships;
|
|
||||||
var $members;
|
|
||||||
|
|
||||||
function read_repository()
|
|
||||||
{
|
|
||||||
/**************************************************************************\
|
|
||||||
* Read values for $this->account_id and put them into $this->data and *
|
|
||||||
* then return $this->data *
|
|
||||||
* *
|
|
||||||
* These are the values that should be set: *
|
|
||||||
* $this->data["account_id"] *
|
|
||||||
* $this->data["account_lid"] *
|
|
||||||
* $this->data["account_type"] *
|
|
||||||
* $this->data["firstname"] *
|
|
||||||
* $this->data["lastname"] *
|
|
||||||
* $this->data["fullname"] *
|
|
||||||
* $this->data["lastlogin"] *
|
|
||||||
* $this->data["lastloginfrom"] *
|
|
||||||
* $this->data["lastpasswd_change"] *
|
|
||||||
* $this->data["status"] *
|
|
||||||
\**************************************************************************/
|
|
||||||
}
|
|
||||||
|
|
||||||
/**************************************************************************\
|
|
||||||
* These are the standard $this->account_id specific functions *
|
|
||||||
\**************************************************************************/
|
|
||||||
|
|
||||||
function save_repository(){
|
|
||||||
/**************************************************************************\
|
|
||||||
* Store the values in $this->data to the repository *
|
|
||||||
\**************************************************************************/
|
|
||||||
}
|
|
||||||
|
|
||||||
/**************************************************************************\
|
|
||||||
* These are the generic functions. Not specific to $this->account_id *
|
|
||||||
\**************************************************************************/
|
|
||||||
|
|
||||||
function add($account_name, $account_type, $first_name, $last_name, $passwd = False) {
|
|
||||||
/**************************************************************************\
|
|
||||||
* Create a new account. Password is optional because of our seperated *
|
|
||||||
* auth class structure *
|
|
||||||
\**************************************************************************/
|
|
||||||
}
|
|
||||||
|
|
||||||
function delete($account_id) {
|
|
||||||
/**************************************************************************\
|
|
||||||
* Accept both acount_name or account_id and use name2id to convert to id *
|
|
||||||
* delete account. I have not worked the details of how hooks will be used *
|
|
||||||
* by apps to delete the users data. For now ignore the issue. *
|
|
||||||
\**************************************************************************/
|
|
||||||
}
|
|
||||||
|
|
||||||
function get_list()
|
|
||||||
{
|
|
||||||
/**************************************************************************\
|
|
||||||
* Return a list of users *
|
|
||||||
\**************************************************************************/
|
|
||||||
}
|
|
||||||
|
|
||||||
function name2id($account_name)
|
|
||||||
{
|
|
||||||
/**************************************************************************\
|
|
||||||
* Return the account_id for the account_name requested *
|
|
||||||
* Return False if you cannot find the given account_name *
|
|
||||||
\**************************************************************************/
|
|
||||||
}
|
|
||||||
|
|
||||||
function id2name($account_id)
|
|
||||||
{
|
|
||||||
/**************************************************************************\
|
|
||||||
* Return the account_id for the account_name requested *
|
|
||||||
* Return False if you cannot find the given account_name *
|
|
||||||
\**************************************************************************/
|
|
||||||
}
|
|
||||||
|
|
||||||
function get_type($account_id)
|
|
||||||
{
|
|
||||||
/**************************************************************************\
|
|
||||||
* Return the account_type for the account_id requested *
|
|
||||||
* Return False if you cannot find the given account_id *
|
|
||||||
\**************************************************************************/
|
|
||||||
}
|
|
||||||
|
|
||||||
function exists($accountname)
|
|
||||||
{
|
|
||||||
/**************************************************************************\
|
|
||||||
* Check to see if an account exists. If string is sent, *
|
|
||||||
* use $this->name2id to get the id. *
|
|
||||||
* Return True or False as appropriate *
|
|
||||||
\**************************************************************************/
|
|
||||||
}
|
|
||||||
|
|
||||||
function auto_add($account_name, $passwd, $default_prefs=False, $default_acls= False)
|
|
||||||
{
|
|
||||||
/**************************************************************************\
|
|
||||||
* This is used to auto create an account. First make sure the account_name *
|
|
||||||
* doesnt exist by using $this->exists and then create the account. *
|
|
||||||
* This function still needs to have some details worked out for dealing *
|
|
||||||
* the default values. *
|
|
||||||
\**************************************************************************/
|
|
||||||
}
|
|
||||||
} //end of class
|
|
||||||
?>
|
|
||||||
@ -1,95 +0,0 @@
|
|||||||
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|
||||||
|
|
||||||
<html>
|
|
||||||
<head>
|
|
||||||
<title>egroupware.org</title>
|
|
||||||
<link rel="STYLESHEET" type="text/css" href="phpgw.css">
|
|
||||||
</head>
|
|
||||||
|
|
||||||
<body link="#ff6600" vlink="#6666aa">
|
|
||||||
|
|
||||||
<center>
|
|
||||||
<table border="0" cellspacing="0" cellpadding="0" width="100%">
|
|
||||||
<tr>
|
|
||||||
<td align="right">
|
|
||||||
<table border="0" cellspacing="3" cellpadding="3">
|
|
||||||
<tr>
|
|
||||||
<td><a href="http://www.egroupware.org/"><img src="../templates/default/images/logo.gif"></a></td>
|
|
||||||
</tr>
|
|
||||||
</table>
|
|
||||||
</td>
|
|
||||||
</tr>
|
|
||||||
<tr>
|
|
||||||
<td valign="top" width="85%">
|
|
||||||
<table border="0" cellpadding="2"><tr><td>
|
|
||||||
<p>You can get your own copy of the eGroupWare CVS tree by using a CVS client from your own system. If you don't already
|
|
||||||
have one, you can find one at <a href="http://www.cvshome.org">http://www.cvshome.org</a>.
|
|
||||||
You can get your own copy of the tree with the commands:</p>
|
|
||||||
|
|
||||||
<pre>cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/egroupware login</pre>
|
|
||||||
|
|
||||||
<p>When it asks you for a password, simply press the Enter key</p>
|
|
||||||
<p>Then type:</p>
|
|
||||||
|
|
||||||
<pre>cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/egroupware co [ -r <TAG> ] <MODULE></pre>
|
|
||||||
|
|
||||||
<p>This will create a <tt><MODULE></tt> directory in your current
|
|
||||||
directory. It may take a bit of time, especially if your network connection
|
|
||||||
is slow or the module is an espeicially large one. But once it is done, you
|
|
||||||
will have an up to date copy of the master CVS source for that module. You
|
|
||||||
can then at any time cd into this directory and type:</p>
|
|
||||||
|
|
||||||
<pre>cvs -z3 update -dP</pre>
|
|
||||||
|
|
||||||
<p>to update your source tree to be in sync with the master tree. (The -z3 sets
|
|
||||||
the compression level)</p>
|
|
||||||
|
|
||||||
<p>The <tt><TAG></tt> refers to the release version that you
|
|
||||||
wish to checkout. At this time, tags that would be of use are:
|
|
||||||
<pre>
|
|
||||||
"Version-0_9_10-branch" - most recent release with patches applied,
|
|
||||||
"HEAD" - a development version and should be treated as such.
|
|
||||||
</pre>
|
|
||||||
</p>
|
|
||||||
|
|
||||||
|
|
||||||
<p>Valid module names are:</p>
|
|
||||||
<table border="0" cellpadding="1" cellspacing="1">
|
|
||||||
<tr><td>egroupware * </td><td>The core eGoupWare libraries</td></tr>
|
|
||||||
<tr><td>phpgwapi * </td><td>The eGoupWare API</td></tr>
|
|
||||||
<tr><td>addressbook * </td><td>an addressbook</td></tr>
|
|
||||||
<tr><td>admin * </td><td>Administration module</td></tr>
|
|
||||||
<tr><td>bookmarks </td><td>Bookmark manager</td></tr>
|
|
||||||
<tr><td>calendar * </td><td>personal/Group calendar</td></tr>
|
|
||||||
<tr><td>comic </td><td>Comic Strip system</td></tr>
|
|
||||||
<tr><td>email * </td><td>EMAIL reader (interfaces to IMAP/POP3)</td></tr>
|
|
||||||
<tr><td>filemanager * </td><td>Personal/Group Filemanagement</td></tr>
|
|
||||||
<tr><td>forum </td><td>A forum system</td></tr>
|
|
||||||
<tr><td>ftp </td><td>web based FTP client</td></tr>
|
|
||||||
<tr><td>headlines </td><td>news site headline system</td></tr>
|
|
||||||
<tr><td>manual * </td><td>online eGoupWare manual</td></tr>
|
|
||||||
<tr><td>news_admin </td><td>create system wide news for your eGoupWare installation</td></tr>
|
|
||||||
<tr><td>polls * </td><td>create/administer polls</td></tr>
|
|
||||||
<tr><td>preferences * </td><td>Manage eGoupWare user preferences</td></tr>
|
|
||||||
<tr><td>projects </td><td>?</td></tr>
|
|
||||||
<tr><td>setup * </td><td>eGoupWare setup</td></tr>
|
|
||||||
<tr><td>stocks </td><td>stock info grabber</td></tr>
|
|
||||||
<tr><td>tts </td><td>Trouble Ticket System</td></tr>
|
|
||||||
</table>
|
|
||||||
|
|
||||||
<p>You should probably check out <code>egroupware</code> first, then
|
|
||||||
<code>cd egroupware</code>, and then check out any additional modules that you
|
|
||||||
want.<br>We suggest at a minimum that you install those modules that mare marked with an "*".</p>
|
|
||||||
|
|
||||||
<p>Please keep in mind that the CVS '-r HEAD' version may not always work correctly,
|
|
||||||
may be unpredictable, etc. The CVS '-r HEAD' version is a development version
|
|
||||||
and should be treated as such.</p>
|
|
||||||
</td></tr></table></td>
|
|
||||||
</tr></table>
|
|
||||||
</td>
|
|
||||||
</tr>
|
|
||||||
</table>
|
|
||||||
</center>
|
|
||||||
|
|
||||||
</body>
|
|
||||||
</html>
|
|
||||||
@ -1,60 +0,0 @@
|
|||||||
-------------------------------
|
|
||||||
- Suggested PHP Configuration -
|
|
||||||
-------------------------------
|
|
||||||
|
|
||||||
This is a suggested php.ini config for running eGroupWare on php4. It
|
|
||||||
is roughly in the order of the paramters in your php.ini file. These recommendations
|
|
||||||
are based on feedback from users and developers.
|
|
||||||
|
|
||||||
RESOURCES
|
|
||||||
max_execution_time = 90
|
|
||||||
This allows for encoding/decoding large file attachments on slower machines and
|
|
||||||
other complex functions.
|
|
||||||
|
|
||||||
memory_limit = 20M
|
|
||||||
At least this value should help with more complex operations.
|
|
||||||
|
|
||||||
ERRORS
|
|
||||||
error_reporting = E_ALL & ~E_NOTICE
|
|
||||||
Having this set to E_ALL, will cause all types of problems if left to
|
|
||||||
display on the screen. E_NOTICE are non-fatal errors such as undefined
|
|
||||||
variable etc. Having this set to E_ALL only will dramatically increase
|
|
||||||
the size of your log files if you log errors.
|
|
||||||
|
|
||||||
display_errors = Off
|
|
||||||
This can cause header output problems if left on. They are better stored in
|
|
||||||
your log file and that way you have a record of any problems.
|
|
||||||
|
|
||||||
log_errors = On
|
|
||||||
See above.
|
|
||||||
|
|
||||||
DATABASES
|
|
||||||
[dbms].allow_persistent = On
|
|
||||||
This must be set to on if you want to use persistent database
|
|
||||||
connections. Change [dbms] to whatever db you want to use, i.e. mysql or
|
|
||||||
pgsql.
|
|
||||||
|
|
||||||
FILE UPLOADING
|
|
||||||
file_uploads = On
|
|
||||||
If you want to use email,phpwebhosting, infolog or any apps that upload files
|
|
||||||
this must be set to on.
|
|
||||||
|
|
||||||
upload_max_filesize = 5M
|
|
||||||
At least this. This will allow for larger email attachments and
|
|
||||||
phpwebhosting files. Use filesize * 4 = memory_limit to allow for
|
|
||||||
base64 encodes.
|
|
||||||
|
|
||||||
PHP4 SESSIONS
|
|
||||||
session.save_path = /tmp
|
|
||||||
Your httpd must be able to read and write to this directory, if you
|
|
||||||
intend to use php4 sessions.
|
|
||||||
|
|
||||||
session.gc_maxlifetime = 1440
|
|
||||||
Set this to what you want to be your session time out limit. It is in
|
|
||||||
seconds, so set it to 3660 if you want it to one hour ... the default is
|
|
||||||
24mins, which is generally too short.
|
|
||||||
|
|
||||||
REGISTER GLOBALS
|
|
||||||
register_globals = On
|
|
||||||
Until release eGroupWare will not work, if the value is set to Off.
|
|
||||||
All further releases will support the Off setting.
|
|
||||||
@ -1,21 +0,0 @@
|
|||||||
body { font-family: Geneva,Arial,Helvetica,sans-serif; font-size: 10pt; }
|
|
||||||
pre { font-family: Lucida Console, monospace; font-size: 10pt; }
|
|
||||||
tt { font-family: Lucida Console, monospace; font-size: 10pt; }
|
|
||||||
td { font-family: Geneva,Arial,Helvetica,sans-serif; font-size: 10pt; }
|
|
||||||
|
|
||||||
.h1 { font-size: 18pt; color: white; font-family: Verdana,Geneva,Arial,Helvetica,sans-serif; }
|
|
||||||
.h1black { font-size: 18pt; color: black; font-family: Verdana,Geneva,Arial,Helvetica,sans-serif; }
|
|
||||||
.h2 { font-size: 14pt; color: #ccccff; }
|
|
||||||
.h2black { font-size: 14pt; color: black; }
|
|
||||||
|
|
||||||
a { color: #333399; text-decoration: underline; }
|
|
||||||
a:visited { color: #6666aa; text-decoration: underline; }
|
|
||||||
a:hover { color: #0000ff; text-decoration: underline; }
|
|
||||||
|
|
||||||
a.side { color: #ff9900; text-decoration: none; }
|
|
||||||
a.side:visited { color: #ffcc66; text-decoration: none; }
|
|
||||||
a.side:hover { color: #ffffcc; text-decoration: underline; }
|
|
||||||
|
|
||||||
a.anchor { color: #000066; text-decoration: none; }
|
|
||||||
|
|
||||||
td.side { color: white; }
|
|
||||||
Binary file not shown.
@ -1,164 +0,0 @@
|
|||||||
#!/usr/bin/perl
|
|
||||||
#Created by Jason Wies (Zone, zone@users.sourceforge.net)
|
|
||||||
#Copyright 2001 Jason Wies
|
|
||||||
#Released under GNU Public License
|
|
||||||
|
|
||||||
#Converts HeaderDoc style inline comments to LyX style LaTeX
|
|
||||||
#Usage: ./inline2lyx.pl file Title Author Date Abstract
|
|
||||||
|
|
||||||
if (!@ARGV[0])
|
|
||||||
{
|
|
||||||
print "Usage: ./inline2lyx.pl file Title Author Date Abstract\n";
|
|
||||||
exit;
|
|
||||||
}
|
|
||||||
|
|
||||||
$output .= '\lyxformat 2.16
|
|
||||||
\textclass linuxdoc
|
|
||||||
\language default
|
|
||||||
\inputencoding latin1
|
|
||||||
\fontscheme default
|
|
||||||
\graphics default
|
|
||||||
\paperfontsize default
|
|
||||||
\spacing single
|
|
||||||
\papersize Default
|
|
||||||
\paperpackage a4
|
|
||||||
\use_geometry 0
|
|
||||||
\use_amsmath 0
|
|
||||||
\paperorientation portrait
|
|
||||||
\secnumdepth 2
|
|
||||||
\tocdepth 2
|
|
||||||
\paragraph_separation indent
|
|
||||||
\defskip medskip
|
|
||||||
\quotes_language english
|
|
||||||
\quotes_times 2
|
|
||||||
\papercolumns 1
|
|
||||||
\papersides 1
|
|
||||||
\paperpagestyle default
|
|
||||||
|
|
||||||
\layout Title
|
|
||||||
\added_space_top vfill \added_space_bottom vfill
|
|
||||||
' . @ARGV[1] . '
|
|
||||||
\layout Author
|
|
||||||
|
|
||||||
' . @ARGV[2] . '
|
|
||||||
|
|
||||||
\layout Date
|
|
||||||
|
|
||||||
' . @ARGV[3] . '
|
|
||||||
|
|
||||||
\layout Abstract
|
|
||||||
|
|
||||||
' . @ARGV[4] . '
|
|
||||||
|
|
||||||
\layout Section
|
|
||||||
|
|
||||||
' . @ARGV[1];
|
|
||||||
|
|
||||||
$file = `cat @ARGV[0]`;
|
|
||||||
|
|
||||||
@lines = split ('\n', $file);
|
|
||||||
|
|
||||||
foreach $line (@lines)
|
|
||||||
{
|
|
||||||
undef $start;
|
|
||||||
undef $class;
|
|
||||||
undef $function;
|
|
||||||
undef $abstract;
|
|
||||||
undef $param;
|
|
||||||
undef $result;
|
|
||||||
undef $discussion;
|
|
||||||
undef $end;
|
|
||||||
undef $layout;
|
|
||||||
|
|
||||||
if ($line =~ /\/\*\!/)
|
|
||||||
{
|
|
||||||
$in = 1;
|
|
||||||
$start = 1;
|
|
||||||
}
|
|
||||||
|
|
||||||
if ($looking && $line =~ /function/)
|
|
||||||
{
|
|
||||||
$layout = "verbatim";
|
|
||||||
undef $looking;
|
|
||||||
}
|
|
||||||
elsif (!$in)
|
|
||||||
{
|
|
||||||
goto next;
|
|
||||||
}
|
|
||||||
|
|
||||||
if ($line =~ /\@(class)/)
|
|
||||||
{
|
|
||||||
$layout = "subsection";
|
|
||||||
$name = $1;
|
|
||||||
$class = 1;
|
|
||||||
}
|
|
||||||
if ($line =~ /\@(function)/)
|
|
||||||
{
|
|
||||||
$layout = "subsection";
|
|
||||||
$name = $1;
|
|
||||||
$function = 1;
|
|
||||||
}
|
|
||||||
if ($line =~ /\@(abstract)/)
|
|
||||||
{
|
|
||||||
$layout = "standard";
|
|
||||||
$name = $1;
|
|
||||||
$abstract = 1;
|
|
||||||
}
|
|
||||||
if ($line =~ /\@(description)/)
|
|
||||||
{
|
|
||||||
$layout = "standard";
|
|
||||||
$name = $1;
|
|
||||||
$description = 1;
|
|
||||||
}
|
|
||||||
if ($line =~ /\@(param)/)
|
|
||||||
{
|
|
||||||
$layout = "standard";
|
|
||||||
$name = $1;
|
|
||||||
$param = 1;
|
|
||||||
}
|
|
||||||
if ($line =~ /\@(result)/)
|
|
||||||
{
|
|
||||||
$layout = "standard";
|
|
||||||
$name = $1;
|
|
||||||
$result = 1;
|
|
||||||
}
|
|
||||||
if ($line =~ /\@(discussion)/)
|
|
||||||
{
|
|
||||||
$layout = "standard";
|
|
||||||
$name = $1;
|
|
||||||
$discussion = 1;
|
|
||||||
}
|
|
||||||
if ($line =~ /\*\// && $in)
|
|
||||||
{
|
|
||||||
undef $in;
|
|
||||||
$looking = 1;
|
|
||||||
$end = 1;
|
|
||||||
}
|
|
||||||
|
|
||||||
if ($layout)
|
|
||||||
{
|
|
||||||
$output .= "\n\n" . '\layout ' . ucfirst ($layout);
|
|
||||||
$line =~ s/\@function//;
|
|
||||||
$line =~ s/\@//;
|
|
||||||
$data = ucfirst ($line);
|
|
||||||
if (!$function && !$class)
|
|
||||||
{
|
|
||||||
$data =~ s/$name/$name:/;
|
|
||||||
}
|
|
||||||
$output .= "\n$data";
|
|
||||||
if ($function || $class)
|
|
||||||
{
|
|
||||||
$output .= "\n" . '\begin_inset LatexCommand \label{sec:' . "$data" . '}' . "\n\n" . '\end_inset';
|
|
||||||
}
|
|
||||||
}
|
|
||||||
elsif ($in && !$start)
|
|
||||||
{
|
|
||||||
$output .= '\layout Standard' . "\n$line";
|
|
||||||
}
|
|
||||||
|
|
||||||
next:
|
|
||||||
}
|
|
||||||
|
|
||||||
$output .= "\n" . '\the_end';
|
|
||||||
|
|
||||||
print $output;
|
|
||||||
@ -1,28 +0,0 @@
|
|||||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
|
|
||||||
<HTML>
|
|
||||||
<HEAD>
|
|
||||||
<META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.17">
|
|
||||||
<TITLE>phpgwapi - VFS Class: Introduction and Purpose</TITLE>
|
|
||||||
<LINK HREF="vfs-2.html" REL=next>
|
|
||||||
|
|
||||||
<LINK HREF="vfs.html#toc1" REL=contents>
|
|
||||||
</HEAD>
|
|
||||||
<BODY>
|
|
||||||
<A HREF="vfs-2.html">Next</A>
|
|
||||||
Previous
|
|
||||||
<A HREF="vfs.html#toc1">Contents</A>
|
|
||||||
<HR>
|
|
||||||
<H2><A NAME="sec:introduction"></A> <A NAME="s1">1.</A> <A HREF="vfs.html#toc1">Introduction and Purpose</A></H2>
|
|
||||||
|
|
||||||
<P>The latest version of the VFS for eGroupWare combines actual
|
|
||||||
file system manipulation with fully integrated database support.
|
|
||||||
It features nearly transparent handling of files and directories,
|
|
||||||
as well as files inside and outside the virtual root. This document
|
|
||||||
is intended to provide API and application developers with a guide
|
|
||||||
to incorporating the VFS into their work.</P>
|
|
||||||
<HR>
|
|
||||||
<A HREF="vfs-2.html">Next</A>
|
|
||||||
Previous
|
|
||||||
<A HREF="vfs.html#toc1">Contents</A>
|
|
||||||
</BODY>
|
|
||||||
</HTML>
|
|
||||||
@ -1,143 +0,0 @@
|
|||||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
|
|
||||||
<HTML>
|
|
||||||
<HEAD>
|
|
||||||
<META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.17">
|
|
||||||
<TITLE>phpgwapi - VFS Class: Basics</TITLE>
|
|
||||||
<LINK HREF="vfs-3.html" REL=next>
|
|
||||||
<LINK HREF="vfs-1.html" REL=previous>
|
|
||||||
<LINK HREF="vfs.html#toc2" REL=contents>
|
|
||||||
</HEAD>
|
|
||||||
<BODY>
|
|
||||||
<A HREF="vfs-3.html">Next</A>
|
|
||||||
<A HREF="vfs-1.html">Previous</A>
|
|
||||||
<A HREF="vfs.html#toc2">Contents</A>
|
|
||||||
<HR>
|
|
||||||
<H2><A NAME="sec:basics"></A> <A NAME="s2">2.</A> <A HREF="vfs.html#toc2">Basics</A></H2>
|
|
||||||
|
|
||||||
<H2><A NAME="sec:prerequisites"></A> <A NAME="ss2.1">2.1</A> <A HREF="vfs.html#toc2.1">Prerequisites</A>
|
|
||||||
</H2>
|
|
||||||
|
|
||||||
<P>You must explicitly enable the VFS class. To do this, set 'enable_vfs_class'
|
|
||||||
to True in $GLOBALS['phpgw_info']['flags'].
|
|
||||||
An example:</P>
|
|
||||||
<P>
|
|
||||||
<PRE>
|
|
||||||
$GLOBALS['phpgw_info']['flags'] = array(
|
|
||||||
'currentapp' => 'filemanaer',
|
|
||||||
'noheader' => False,
|
|
||||||
'noappheader' => False,
|
|
||||||
'enable_vfs_class' => True,
|
|
||||||
'enable_browser_class' => True
|
|
||||||
);
|
|
||||||
</PRE>
|
|
||||||
</P>
|
|
||||||
<H2><A NAME="sec:concepts"></A> <A NAME="ss2.2">2.2</A> <A HREF="vfs.html#toc2.2">Concepts</A>
|
|
||||||
</H2>
|
|
||||||
|
|
||||||
<P>The VFS in located in phpgwapi/inc/class.vfs_sql.inc.php. You
|
|
||||||
can look over it, but I don't suggest trying to understand how it
|
|
||||||
works. It isn't necessary to know its internals to use it, but you
|
|
||||||
may find the inline comments helpful. The basic things to keep in
|
|
||||||
mind:</P>
|
|
||||||
<P>
|
|
||||||
<UL>
|
|
||||||
<LI>Files and directories are synonymous in almost all cases</LI>
|
|
||||||
</UL>
|
|
||||||
</P>
|
|
||||||
<P>
|
|
||||||
<PRE>
|
|
||||||
$GLOBALS['phpgw']->vfs->mv (array(
|
|
||||||
'from' => 'file1',
|
|
||||||
'to' => 'dir/file2'
|
|
||||||
));
|
|
||||||
|
|
||||||
$GLOBALS['phpgw']->vfs->mv (array(
|
|
||||||
'from' => 'dir1',
|
|
||||||
'to' => 'dir/dir1'
|
|
||||||
));
|
|
||||||
|
|
||||||
$GLOBALS['phpgw']->vfs->rm (array(
|
|
||||||
'string' => 'file'
|
|
||||||
));
|
|
||||||
|
|
||||||
$GLOBALS['phpgw']->vfs->rm (array(
|
|
||||||
'string' => 'dir'
|
|
||||||
));
|
|
||||||
</PRE>
|
|
||||||
</P>
|
|
||||||
<P>All work as you would except them to. The major exception is:</P>
|
|
||||||
<P>
|
|
||||||
<PRE>
|
|
||||||
$GLOBALS['phpgw']->vfs->touch (array(
|
|
||||||
'string' => 'file'
|
|
||||||
));
|
|
||||||
</PRE>
|
|
||||||
</P>
|
|
||||||
<P>vs.</P>
|
|
||||||
<P>
|
|
||||||
<PRE>
|
|
||||||
$GLOBALS['phpgw']->vfs->mkdir (array(
|
|
||||||
'string' => 'dir'
|
|
||||||
));
|
|
||||||
</PRE>
|
|
||||||
</P>
|
|
||||||
<P>
|
|
||||||
<UL>
|
|
||||||
<LI>Users and groups are synonymous</LI>
|
|
||||||
</UL>
|
|
||||||
</P>
|
|
||||||
<P>As far as the actual paths are concerned, users and groups are
|
|
||||||
the same. /home/username works the same as /home/groupname.</P>
|
|
||||||
<P>
|
|
||||||
<UL>
|
|
||||||
<LI>You should never have to know the real paths of files</LI>
|
|
||||||
</UL>
|
|
||||||
</P>
|
|
||||||
<P>One of the VFS's responsibilities is to translate paths for you.
|
|
||||||
While you certainly <EM>can</EM> operate using full paths, it is much simpler
|
|
||||||
to use the virtual paths. For example, instead of using:</P>
|
|
||||||
<P>
|
|
||||||
<PRE>
|
|
||||||
$GLOBALS['phpgw']->vfs->cp (array(
|
|
||||||
'from' => '/var/www/egroupware/files/home/user/file1',
|
|
||||||
'to' => '/var/www/egroupware/files/home/user/file2',
|
|
||||||
'relatives' => array(
|
|
||||||
RELATIVE_NONE|VFS_REAL,
|
|
||||||
RELATIVE_NONE|VFS_REAL
|
|
||||||
)
|
|
||||||
));
|
|
||||||
</PRE>
|
|
||||||
</P>
|
|
||||||
<P>you might use</P>
|
|
||||||
<P>
|
|
||||||
<PRE>
|
|
||||||
$GLOBALS['phpgw']->vfs->cp (array(
|
|
||||||
'from' => '/home/user/file1',
|
|
||||||
'to' => '/home/user/file2',
|
|
||||||
'relatives' => array(
|
|
||||||
RELATIVE_NONE,
|
|
||||||
RELATIVE_NONE
|
|
||||||
)
|
|
||||||
));
|
|
||||||
</PRE>
|
|
||||||
</P>
|
|
||||||
<P>(We'll get to the RELATIVE's in a minute.)</P>
|
|
||||||
<P>Site administrators should be able to move their files dir around
|
|
||||||
on their system and know that everything will continue to work smoothly.</P>
|
|
||||||
<P>
|
|
||||||
<UL>
|
|
||||||
<LI>Relativity is <EM>vital</EM></LI>
|
|
||||||
</UL>
|
|
||||||
</P>
|
|
||||||
<P>Relativity is a new feature in the VFS, and its importance cannot
|
|
||||||
be stressed enough. It will make your life much easier, especially
|
|
||||||
for file system intensive applications, but it will take some getting
|
|
||||||
used to. If something doesn't work right the first time, chances
|
|
||||||
are great it has to do with incorrect relativity settings. We will
|
|
||||||
deal with relativity in depth in the Relativity section.</P>
|
|
||||||
<HR>
|
|
||||||
<A HREF="vfs-3.html">Next</A>
|
|
||||||
<A HREF="vfs-1.html">Previous</A>
|
|
||||||
<A HREF="vfs.html#toc2">Contents</A>
|
|
||||||
</BODY>
|
|
||||||
</HTML>
|
|
||||||
@ -1,130 +0,0 @@
|
|||||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
|
|
||||||
<HTML>
|
|
||||||
<HEAD>
|
|
||||||
<META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.17">
|
|
||||||
<TITLE>phpgwapi - VFS Class: Basic Functions</TITLE>
|
|
||||||
<LINK HREF="vfs-4.html" REL=next>
|
|
||||||
<LINK HREF="vfs-2.html" REL=previous>
|
|
||||||
<LINK HREF="vfs.html#toc3" REL=contents>
|
|
||||||
</HEAD>
|
|
||||||
<BODY>
|
|
||||||
<A HREF="vfs-4.html">Next</A>
|
|
||||||
<A HREF="vfs-2.html">Previous</A>
|
|
||||||
<A HREF="vfs.html#toc3">Contents</A>
|
|
||||||
<HR>
|
|
||||||
<H2><A NAME="sec:basic_functions"></A> <A NAME="s3">3.</A> <A HREF="vfs.html#toc3">Basic Functions</A></H2>
|
|
||||||
|
|
||||||
<P>These are two functions you'll need to know before we get into
|
|
||||||
relativity.</P>
|
|
||||||
<H2><A NAME="sec:path_parts"></A> <A NAME="ss3.1">3.1</A> <A HREF="vfs.html#toc3.1">path_parts ()</A>
|
|
||||||
</H2>
|
|
||||||
|
|
||||||
<P>The job of path_parts () is to translate any given file location
|
|
||||||
into its many component parts for any relativity. The values passed
|
|
||||||
to path_parts () are:</P>
|
|
||||||
<P>
|
|
||||||
<PRE>
|
|
||||||
string
|
|
||||||
relatives
|
|
||||||
object
|
|
||||||
</PRE>
|
|
||||||
</P>
|
|
||||||
<P>'string' is the path you want to translate, 'relatives' is the
|
|
||||||
standard relativity array, and 'object' specifies how you would like
|
|
||||||
the return value: if 'object' is True, an object will be returned;
|
|
||||||
if 'object' is False, an array will be returned. I think you'll find
|
|
||||||
the object easier to deal with, and we'll be using it throughout
|
|
||||||
this document. The most important returned values (but not all) for
|
|
||||||
path_parts () are:</P>
|
|
||||||
<P>
|
|
||||||
<PRE>
|
|
||||||
fake_full_path
|
|
||||||
fake_leading_dirs
|
|
||||||
fake_extra_path
|
|
||||||
fake_name
|
|
||||||
real_full_path
|
|
||||||
real_leading_dirs
|
|
||||||
real_extra_path
|
|
||||||
real_name
|
|
||||||
</PRE>
|
|
||||||
</P>
|
|
||||||
<P>Just like you would think, fake_full_path contains the full virtual
|
|
||||||
path of 'string', and real_full_path contains the full real path
|
|
||||||
of 'string'. The fake_name and real_name variables should always
|
|
||||||
be the same, and contain the final file or directory name. The leading_dirs
|
|
||||||
contain everything except the name, and the extra_path is everything
|
|
||||||
from the / before "home" to the end of the leading_dirs. To better
|
|
||||||
illustrate, here is an example:</P>
|
|
||||||
<P>
|
|
||||||
<PRE>
|
|
||||||
$p = $GLOBALS['phpgw']->vfs->path_parts (array(
|
|
||||||
'string' => '/home/jason/dir/file',
|
|
||||||
'relatives' => array(
|
|
||||||
RELATIVE_NONE
|
|
||||||
)
|
|
||||||
));
|
|
||||||
</PRE>
|
|
||||||
</P>
|
|
||||||
<P>
|
|
||||||
<UL>
|
|
||||||
<LI>$p->fake_full_path - /home/jason/dir/file</LI>
|
|
||||||
<LI>$p->fake_leading_dirs - /home/jason/dir</LI>
|
|
||||||
<LI>$p->fake_extra_path - home/jason/dir</LI>
|
|
||||||
<LI>$p->fake_name - file</LI>
|
|
||||||
<LI>$p->real_full_path - /var/www/egroupware/files/home/jason/dir/file</LI>
|
|
||||||
<LI>$p->real_leading_dirs - /var/www/egroupware/files/home/jason/dir
|
|
||||||
</LI>
|
|
||||||
<LI>$p->real_extra_path - home/jason/dir</LI>
|
|
||||||
<LI>$p->real_name - file</LI>
|
|
||||||
</UL>
|
|
||||||
</P>
|
|
||||||
<P>As you can see, path_parts () is a very useful function and will
|
|
||||||
save you from doing those darn substr ()'s yourself. For those of
|
|
||||||
you used to the prior VFS, note that <EM>getabsolutepath () is depreciated</EM>.
|
|
||||||
getabsolutepath () still exists (albeit in a much different form),
|
|
||||||
and is responsible for some of the path translation, but it is an
|
|
||||||
<EM>internal</EM> function only. Applications should only use path_parts ().
|
|
||||||
We have shown you how to use path_parts () so you can experiment
|
|
||||||
with it using different paths and relativities as we explore relativity.</P>
|
|
||||||
<H2><A NAME="sec:cd"></A> <A NAME="ss3.2">3.2</A> <A HREF="vfs.html#toc3.2">cd ()</A>
|
|
||||||
</H2>
|
|
||||||
|
|
||||||
<P>Part of the overall goal for the VFS in eGroupWare is to give
|
|
||||||
the user a seamless experience during their session. For example,
|
|
||||||
if they upload a file using a file manager to the directory /home/my_group/project1,
|
|
||||||
and then go to download an email attachment, the default directory
|
|
||||||
will be /home/my_group/project1. This is accomplished using the cd
|
|
||||||
() function. Examples: </P>
|
|
||||||
<P>
|
|
||||||
<PRE>
|
|
||||||
/* cd to their home directory */
|
|
||||||
$GLOBALS['phpgw']->vfs->cd (array(
|
|
||||||
'string' => '/'
|
|
||||||
));
|
|
||||||
|
|
||||||
/* cd to /home/jason/dir */
|
|
||||||
$GLOBALS['phpgw']->vfs->cd (array(
|
|
||||||
'string' => '/home/jason/dir',
|
|
||||||
'relative' => False,
|
|
||||||
'relatives' => array(
|
|
||||||
RELATIVE_NONE
|
|
||||||
)
|
|
||||||
));
|
|
||||||
|
|
||||||
/* When following the above, cd's to /home/jason/dir/dir2 */
|
|
||||||
$GLOBALS['phpgw']->vfs->cd (array(
|
|
||||||
'string' => 'dir2',
|
|
||||||
'relative' => True
|
|
||||||
));
|
|
||||||
</PRE>
|
|
||||||
</P>
|
|
||||||
<P>If 'relative' is True, the 'string' is simply appended to the
|
|
||||||
current path. If you want to know what the current path is, use $GLOBALS['phpgw']->vfs->pwd
|
|
||||||
().</P>
|
|
||||||
<P>Now you're ready for relativity.</P>
|
|
||||||
<HR>
|
|
||||||
<A HREF="vfs-4.html">Next</A>
|
|
||||||
<A HREF="vfs-2.html">Previous</A>
|
|
||||||
<A HREF="vfs.html#toc3">Contents</A>
|
|
||||||
</BODY>
|
|
||||||
</HTML>
|
|
||||||
@ -1,201 +0,0 @@
|
|||||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
|
|
||||||
<HTML>
|
|
||||||
<HEAD>
|
|
||||||
<META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.17">
|
|
||||||
<TITLE>phpgwapi - VFS Class: Relativity</TITLE>
|
|
||||||
<LINK HREF="vfs-5.html" REL=next>
|
|
||||||
<LINK HREF="vfs-3.html" REL=previous>
|
|
||||||
<LINK HREF="vfs.html#toc4" REL=contents>
|
|
||||||
</HEAD>
|
|
||||||
<BODY>
|
|
||||||
<A HREF="vfs-5.html">Next</A>
|
|
||||||
<A HREF="vfs-3.html">Previous</A>
|
|
||||||
<A HREF="vfs.html#toc4">Contents</A>
|
|
||||||
<HR>
|
|
||||||
<H2><A NAME="sec:relativity"></A> <A NAME="s4">4.</A> <A HREF="vfs.html#toc4">Relativity</A></H2>
|
|
||||||
|
|
||||||
<P>Ok, just one last thing before we get into relativity. You will
|
|
||||||
notice throughout the examples the use of $fakebase. $GLOBALS['phpgw']->vfs->fakebase
|
|
||||||
is by default '/home'. The old VFS was hard-coded to use '/home',
|
|
||||||
but the naming choice for this is now up to administrators. See the
|
|
||||||
<A HREF="vfs-6.html#sec:fakebase">Fakebase directory (changing /home)</A> section for more information. Throughout the rest of this document,
|
|
||||||
you will see $fakebase used in calls to the VFS, and /home
|
|
||||||
used in actual paths. <EM>You should always use $fakebase when
|
|
||||||
making applications. </EM>I suggest doing $fakebase = $GLOBALS['phpgw']->vfs->fakebase;
|
|
||||||
right off the bat to keep things neater.</P>
|
|
||||||
<H2><A NAME="ss4.1">4.1</A> <A HREF="vfs.html#toc4.1">What is it and how does it work?</A>
|
|
||||||
</H2>
|
|
||||||
|
|
||||||
<P>One of the design challenges for a Virtual File System is to
|
|
||||||
try to figure out whether the calling application is referring to
|
|
||||||
a file inside or outside the virtual root, and if inside, exactly
|
|
||||||
where. To solve this problem, the eGoupWare VFS uses RELATIVE
|
|
||||||
defines that are used in bitmasks passed to each function. The result
|
|
||||||
is that any set of different relativities can be used in combination
|
|
||||||
with each other. Let's look at a few examples. Say you want to move
|
|
||||||
'logo.png' from the user's home directory to the current directory.</P>
|
|
||||||
|
|
||||||
<P>
|
|
||||||
<PRE>
|
|
||||||
$GLOBALS['phpgw']->vfs->mv (array(
|
|
||||||
'from' => 'logo.png',
|
|
||||||
'to' => 'logo.png',
|
|
||||||
'relatives' => array(
|
|
||||||
RELATIVE_USER,
|
|
||||||
RELATIVE_ALL
|
|
||||||
)
|
|
||||||
));
|
|
||||||
</PRE>
|
|
||||||
</P>
|
|
||||||
<P>RELATIVE_USER means relative to the user's home directory. RELATIVE_ALL
|
|
||||||
means relative to the current directory, as set by cd () and as reported
|
|
||||||
by pwd (). So if the current directory was "$fakebase/my_group/project1",
|
|
||||||
the call to mv () would be processed as:</P>
|
|
||||||
<P>
|
|
||||||
<PRE>
|
|
||||||
MOVE "$fakebase/jason/logo.png" TO "$fakebase/my_group/project1/logo.png"
|
|
||||||
</PRE>
|
|
||||||
</P>
|
|
||||||
<P>and the actual file system call would be:</P>
|
|
||||||
<P>
|
|
||||||
<PRE>
|
|
||||||
rename ('/var/www/egroupware/files/home/jason/logo.php', '/var/www/egroupware/files/home/my_group/project1/logo.png');
|
|
||||||
</PRE>
|
|
||||||
</P>
|
|
||||||
<P>Those used to the old VFS will note that you do not have to translate
|
|
||||||
the path beforehand. Let's look at another example. Suppose you were
|
|
||||||
moving an email attachment stored in eGoupWare's temporary directory
|
|
||||||
to the 'attachments' directory within the user's home directory (we're
|
|
||||||
assuming the attachments directory exists). Note that the temporary
|
|
||||||
directory is <EM>outside</EM> the virtual root.</P>
|
|
||||||
<P>
|
|
||||||
<PRE>
|
|
||||||
$GLOBALS['phpgw']->vfs->mv (array(
|
|
||||||
'from' => $GLOBALS['phpgw_info']['server']['temp_dir'] . '/' . $randomdir . '/' . $randomfile,
|
|
||||||
'to' => 'attachments/actual_name.ext',
|
|
||||||
'relatives' => array(
|
|
||||||
RELATIVE_NONE|VFS_REAL,
|
|
||||||
RELATIVE_USER
|
|
||||||
)
|
|
||||||
));
|
|
||||||
</PRE>
|
|
||||||
</P>
|
|
||||||
<P>$randomdir and $randomfile are what the directory
|
|
||||||
and file might be called before they are given a proper name by the
|
|
||||||
user, which is actual_name.ext in this example. RELATIVE_NONE is
|
|
||||||
the define for using full path names. However, RELATIVE_NONE is still
|
|
||||||
relative to the virtual root, so we pass along VFS_REAL as well,
|
|
||||||
to say that the file is <EM>outside</EM> the virtual root, somewhere else
|
|
||||||
in the file system. Once again, RELATIVE_USER means relative to the
|
|
||||||
user's home directory. So the actual file system call might look
|
|
||||||
like this (keep in mind that $randomdir and $randomfile
|
|
||||||
are just random strings):</P>
|
|
||||||
<P>
|
|
||||||
<PRE>
|
|
||||||
rename ('/var/www/egroupware/tmp/0ak5adftgh7/jX42sC9M', '/var/www/egroupware/files/home/jason/attachments/actual_name.ext');
|
|
||||||
</PRE>
|
|
||||||
</P>
|
|
||||||
<P>Of course you don't have to know that, nor should you be concerned
|
|
||||||
with it; you can take it for granted that the VFS will translate
|
|
||||||
the paths correctly. Let's take a look at one more example, this
|
|
||||||
time using the RELATIVE_USER_APP define. RELATIVE_USER_APP is used
|
|
||||||
to store quasi-hidden application files, similar to the Unix convention
|
|
||||||
of ~/.appname. It simply appends .appname to the user's home
|
|
||||||
directory. For example, if you were making an HTML editor application
|
|
||||||
named 'htmledit', and wanted to keep a backup file in case something
|
|
||||||
goes wrong, you could use RELATIVE_USER_APP to store it:</P>
|
|
||||||
<P>
|
|
||||||
<PRE>
|
|
||||||
$GLOBALS['phpgw']->vfs->write (array(
|
|
||||||
'string' => 'file.name~',
|
|
||||||
'relatives' => array(
|
|
||||||
RELATIVE_USER_APP
|
|
||||||
),
|
|
||||||
'content' => $contents
|
|
||||||
));
|
|
||||||
</PRE>
|
|
||||||
</P>
|
|
||||||
<P>This assumes that ~/.htmledit exists of course. The backup
|
|
||||||
file "file.name~" would then be written in $fakebase/jason/.htmledit/file.name~.
|
|
||||||
Note that storing files like this might not be as good of a solution
|
|
||||||
as storing them in the temporary directory or in the database. But
|
|
||||||
it is there in case you need it.</P>
|
|
||||||
<H2><A NAME="sec:relatives_complete_list"></A> <A NAME="ss4.2">4.2</A> <A HREF="vfs.html#toc4.2">Complete List</A>
|
|
||||||
</H2>
|
|
||||||
|
|
||||||
<P>Here is the complete list of RELATIVE defines, and what they
|
|
||||||
do:</P>
|
|
||||||
<P>
|
|
||||||
<DL>
|
|
||||||
<DT><B>RELATIVE_ROOT</B><DD><P>Don't translate the path at all. Just prepends
|
|
||||||
a /. You'll probably want to use RELATIVE_NONE though, which handles
|
|
||||||
both virtual and real files.</P>
|
|
||||||
<DT><B>RELATIVE_USER</B><DD><P>User's home directory</P>
|
|
||||||
<DT><B>RELATIVE_CURR_USER</B><DD><P>Current user's home directory. If the
|
|
||||||
current directory is $fakebase/my_group/project1, this will
|
|
||||||
return is $fakebase/my_group</P>
|
|
||||||
<DT><B>RELATIVE_USER_APP</B><DD><P>Append .appname to the user's home directory,
|
|
||||||
where appname is the current application's appname</P>
|
|
||||||
<DT><B>RELATIVE_PATH</B><DD><P>DO NOT USE. Relative to the current directory,
|
|
||||||
used in RELATIVE_ALL</P>
|
|
||||||
<DT><B>RELATIVE_NONE</B><DD><P>Not relative to anything. Use this with VFS_REAL
|
|
||||||
for files outside the virtual root. Note that using RELATIVE_NONE
|
|
||||||
by itself still means relative to the virtual root</P>
|
|
||||||
<DT><B>RELATIVE_CURRENT</B><DD><P>An alias for the currently set RELATIVE
|
|
||||||
define, or RELATIVE_ALL if none is set (see the Defaults section)</P>
|
|
||||||
<DT><B>VFS_REAL</B><DD><P>File is outside of the virtual root. Usually used
|
|
||||||
with RELATIVE_NONE</P>
|
|
||||||
<DT><B>RELATIVE_ALL</B><DD><P>Relative to the current directory. Use RELATIVE_ALL<EM></EM>instead of RELATIVE_PATH</P>
|
|
||||||
</DL>
|
|
||||||
</P>
|
|
||||||
<H2><A NAME="sec:relatives_defaults"></A> <A NAME="ss4.3">4.3</A> <A HREF="vfs.html#toc4.3">Defaults</A>
|
|
||||||
</H2>
|
|
||||||
|
|
||||||
<P>You might be thinking to yourself that passing along RELATIVE
|
|
||||||
defines with every VFS call is overkill, especially if your application
|
|
||||||
always uses the same relativity. The default RELATIVE define for
|
|
||||||
all VFS calls is RELATIVE_CURRENT. RELATIVE_CURRENT itself defaults
|
|
||||||
to RELATIVE_ALL (relative to the current path), <EM>unless</EM> your application
|
|
||||||
sets a specific relativity. If your application requires most of
|
|
||||||
the work to be done outside of the virtual root, you may wish to
|
|
||||||
set RELATIVE_CURRENT to RELATIVE_NONE|VFS_REAL. set_relative () is
|
|
||||||
the function to do this. For example:</P>
|
|
||||||
<P>
|
|
||||||
<PRE>
|
|
||||||
$GLOBALS['phpgw']->vfs->set_relative (array(
|
|
||||||
'mask' => RELATIVE_NONE|VFS_REAL
|
|
||||||
));
|
|
||||||
|
|
||||||
$GLOBALS['phpgw']->vfs->read (array(
|
|
||||||
'string' => '/etc/passwd'
|
|
||||||
));
|
|
||||||
|
|
||||||
$GLOBALS['phpgw']->vfs->cp (array(
|
|
||||||
'from' => '/usr/include/stdio.h',
|
|
||||||
'to' => '/tmp/stdio.h'
|
|
||||||
));
|
|
||||||
|
|
||||||
$GLOBALS['phpgw']->vfs->cp (array(
|
|
||||||
'from' => '/usr/share/pixmaps/yes.xpm',
|
|
||||||
'to' => 'icons/yes.xpm',
|
|
||||||
'relatives' => array(
|
|
||||||
RELATIVE_CURRENT,
|
|
||||||
RELATIVE_USER
|
|
||||||
)
|
|
||||||
));
|
|
||||||
</PRE>
|
|
||||||
</P>
|
|
||||||
<P>You should notice that no relativity array is needed in the other
|
|
||||||
calls that refer to files outside the virtual root, but one is needed
|
|
||||||
for calls that include files inside the virtual root. Any RELATIVE
|
|
||||||
define can be set as the default and works in the same fashion. To
|
|
||||||
retrieve the currently set define, use get_relative (). Note that
|
|
||||||
the relativity is reset after each page request; that is, it's good
|
|
||||||
only for the life of the current page loading, and is not stored
|
|
||||||
in session management.</P>
|
|
||||||
<HR>
|
|
||||||
<A HREF="vfs-5.html">Next</A>
|
|
||||||
<A HREF="vfs-3.html">Previous</A>
|
|
||||||
<A HREF="vfs.html#toc4">Contents</A>
|
|
||||||
</BODY>
|
|
||||||
</HTML>
|
|
||||||
@ -1,25 +0,0 @@
|
|||||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
|
|
||||||
<HTML>
|
|
||||||
<HEAD>
|
|
||||||
<META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.17">
|
|
||||||
<TITLE>phpgwapi - VFS Class: Function reference</TITLE>
|
|
||||||
<LINK HREF="vfs-6.html" REL=next>
|
|
||||||
<LINK HREF="vfs-4.html" REL=previous>
|
|
||||||
<LINK HREF="vfs.html#toc5" REL=contents>
|
|
||||||
</HEAD>
|
|
||||||
<BODY>
|
|
||||||
<A HREF="vfs-6.html">Next</A>
|
|
||||||
<A HREF="vfs-4.html">Previous</A>
|
|
||||||
<A HREF="vfs.html#toc5">Contents</A>
|
|
||||||
<HR>
|
|
||||||
<H2><A NAME="sec:function_reference"></A> <A NAME="s5">5.</A> <A HREF="vfs.html#toc5">Function reference</A></H2>
|
|
||||||
|
|
||||||
<P>To view the function reference for the VFS, use the doc/inlinedocparser.php
|
|
||||||
script that comes with eGroupWare, ie
|
|
||||||
<A HREF="http://localhost/doc/inlinedocparser.php?fn=class.vfs_sql.inc.php">http://localhost/doc/inlinedocparser.php?fn=class.vfs_sql.inc.php</A>.</P>
|
|
||||||
<HR>
|
|
||||||
<A HREF="vfs-6.html">Next</A>
|
|
||||||
<A HREF="vfs-4.html">Previous</A>
|
|
||||||
<A HREF="vfs.html#toc5">Contents</A>
|
|
||||||
</BODY>
|
|
||||||
</HTML>
|
|
||||||
@ -1,110 +0,0 @@
|
|||||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
|
|
||||||
<HTML>
|
|
||||||
<HEAD>
|
|
||||||
<META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.17">
|
|
||||||
<TITLE>phpgwapi - VFS Class: Notes</TITLE>
|
|
||||||
<LINK HREF="vfs-7.html" REL=next>
|
|
||||||
<LINK HREF="vfs-5.html" REL=previous>
|
|
||||||
<LINK HREF="vfs.html#toc6" REL=contents>
|
|
||||||
</HEAD>
|
|
||||||
<BODY>
|
|
||||||
<A HREF="vfs-7.html">Next</A>
|
|
||||||
<A HREF="vfs-5.html">Previous</A>
|
|
||||||
<A HREF="vfs.html#toc6">Contents</A>
|
|
||||||
<HR>
|
|
||||||
<H2><A NAME="sec:notes"></A> <A NAME="s6">6.</A> <A HREF="vfs.html#toc6">Notes</A></H2>
|
|
||||||
|
|
||||||
<H2><A NAME="sec:database"></A> <A NAME="ss6.1">6.1</A> <A HREF="vfs.html#toc6.1">Database</A>
|
|
||||||
</H2>
|
|
||||||
|
|
||||||
<P>Data about the files and directories within the virtual root
|
|
||||||
is kept in the SQL database. Currently, this information includes:</P>
|
|
||||||
<P>
|
|
||||||
<UL>
|
|
||||||
<LI>File ID (used internally, primary key for table)</LI>
|
|
||||||
<LI>Owner ID (phpGW account_id)</LI>
|
|
||||||
<LI>Created by ID (phpGW account_id)</LI>
|
|
||||||
<LI>Modified by ID (phpGW account_id)</LI>
|
|
||||||
<LI>Created (date)</LI>
|
|
||||||
<LI>Modified (date)</LI>
|
|
||||||
<LI>Size (bytes)</LI>
|
|
||||||
<LI>MIME type</LI>
|
|
||||||
<LI>Deleteable (Y/N/Other?)</LI>
|
|
||||||
<LI>Comment</LI>
|
|
||||||
<LI>App (appname of application that created the file)</LI>
|
|
||||||
<LI>Directory (directory the file or directory is in)</LI>
|
|
||||||
<LI>Name (name of file or directory)</LI>
|
|
||||||
<LI>Link directory (if the file or directory is linked, what the
|
|
||||||
actual directory is)</LI>
|
|
||||||
<LI>Link name (if the file or directory is linked, what the actual
|
|
||||||
name is)</LI>
|
|
||||||
<LI>Version (numeric version of the file)</LI>
|
|
||||||
</UL>
|
|
||||||
</P>
|
|
||||||
<P>The internal names of these (the database column names) are stored
|
|
||||||
in the $GLOBALS['phpgw']->vfs->attributes
|
|
||||||
array, which is useful for loops, and is guaranteed to be up-to-date.</P>
|
|
||||||
<P>Note that no information is kept about files outside the virtual
|
|
||||||
root. If a file is moved outside, all records of it are deleted from
|
|
||||||
the database (other than the journaling records). If a file is moved
|
|
||||||
into the virtual root, some information, specifically MIME-type,
|
|
||||||
is not always stored in the database. The vital information has defaults:
|
|
||||||
owner is based on where the file is being stored; size is correctly
|
|
||||||
read; deleteable is set to Y.</P>
|
|
||||||
<H2><A NAME="sec:acl_support"></A> <A NAME="ss6.2">6.2</A> <A HREF="vfs.html#toc6.2">ACL support</A>
|
|
||||||
</H2>
|
|
||||||
|
|
||||||
<P>ACL support is built into the VFS. vfs->acl_check () does
|
|
||||||
the actual checking, and is called from all VFS functions as needed.
|
|
||||||
If the file or directory sent to acl_check () doesn't exist, the
|
|
||||||
permissions for the parent directory are used to determine access.
|
|
||||||
ACL checking can be overridden at any time by setting vfs->override_acl.
|
|
||||||
For example:</P>
|
|
||||||
<P>
|
|
||||||
<PRE>
|
|
||||||
$GLOBALS['phpgw']->vfs->override_acl = 1;
|
|
||||||
$GLOBALS['phpgw']->vfs->mkdir (array(
|
|
||||||
'string' => $GLOBALS['fakebase']. '/' . $group_array['account_name'],
|
|
||||||
'relatives' => array(
|
|
||||||
RELATIVE_NONE
|
|
||||||
)
|
|
||||||
));
|
|
||||||
$GLOBALS['phpgw']->vfs->override_acl = 0;
|
|
||||||
</PRE>
|
|
||||||
</P>
|
|
||||||
<H2><A NAME="sec:function_aliases"></A> <A NAME="ss6.3">6.3</A> <A HREF="vfs.html#toc6.3">Function aliases</A>
|
|
||||||
</H2>
|
|
||||||
|
|
||||||
<P>You might have noticed there are some functions that just pass
|
|
||||||
the arguments on to other functions. These are provided in part because
|
|
||||||
of legacy and in part for convenience. You can use either. Here is
|
|
||||||
the list (alias -> actual):</P>
|
|
||||||
<P>
|
|
||||||
<UL>
|
|
||||||
<LI>copy -> cp</LI>
|
|
||||||
<LI>move -> rm</LI>
|
|
||||||
<LI>delete -> rm</LI>
|
|
||||||
<LI>dir -> ls</LI>
|
|
||||||
</UL>
|
|
||||||
</P>
|
|
||||||
<H2><A NAME="sec:fakebase"></A> <A NAME="ss6.4">6.4</A> <A HREF="vfs.html#toc6.4">Fakebase directory (changing /home)</A>
|
|
||||||
</H2>
|
|
||||||
|
|
||||||
<P>The old VFS was hard-coded to use '/home' as the fake base directory,
|
|
||||||
even though the user never saw it. With the new system, crafty administrators
|
|
||||||
may wish to change '/home' to something else, say '/users' or '/public_html'.
|
|
||||||
The fake base directory name is stored in $GLOBALS['phpgw']->vfs->fakebase,
|
|
||||||
and changing it will transparently change it throughout the VFS and
|
|
||||||
all applications. However, this must be done <EM>before</EM> any data is in
|
|
||||||
the VFS database. If you wish to change it afterwords, you'll have
|
|
||||||
to manually update the database, replacing the old value with the
|
|
||||||
new value. <EM>Application programmers need to recognize that /home is
|
|
||||||
not absolute, and use $GLOBALS['phpgw']->vfs->fakebase
|
|
||||||
instead</EM>. I suggest setting $fakebase = $GLOBALS['phpgw']->vfs->fakebase;
|
|
||||||
right off the bat to keep things neater.</P>
|
|
||||||
<HR>
|
|
||||||
<A HREF="vfs-7.html">Next</A>
|
|
||||||
<A HREF="vfs-5.html">Previous</A>
|
|
||||||
<A HREF="vfs.html#toc6">Contents</A>
|
|
||||||
</BODY>
|
|
||||||
</HTML>
|
|
||||||
@ -1,42 +0,0 @@
|
|||||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
|
|
||||||
<HTML>
|
|
||||||
<HEAD>
|
|
||||||
<META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.17">
|
|
||||||
<TITLE>phpgwapi - VFS Class: About this Document</TITLE>
|
|
||||||
<LINK HREF="vfs-6.html" REL=previous>
|
|
||||||
<LINK HREF="vfs.html#toc7" REL=contents>
|
|
||||||
</HEAD>
|
|
||||||
<BODY>
|
|
||||||
Next
|
|
||||||
<A HREF="vfs-6.html">Previous</A>
|
|
||||||
<A HREF="vfs.html#toc7">Contents</A>
|
|
||||||
<HR>
|
|
||||||
<H2><A NAME="s7">7.</A> <A HREF="vfs.html#toc7">About this Document</A></H2>
|
|
||||||
|
|
||||||
<H2><A NAME="ss7.1">7.1</A> <A HREF="vfs.html#toc7.1">Copyright and License</A>
|
|
||||||
</H2>
|
|
||||||
|
|
||||||
<P>Copyright (c) 2001, 2002 Jason Wies</P>
|
|
||||||
<P>Permission is granted to copy, distribute and/or modify this
|
|
||||||
document under the terms of the GNU Free Documentation License, Version
|
|
||||||
1.1 or any later version published by the Free Software Foundation;
|
|
||||||
with no Invarient Sections, with no Front-Cover Texts, and no Back-Cover
|
|
||||||
Texts.</P>
|
|
||||||
<P>A copy of the license is available at
|
|
||||||
<A HREF="http://www.gnu.org/copyleft/fdl.html">http://www.gnu.org/copyleft/fdl.html</A>.</P>
|
|
||||||
<H2><A NAME="ss7.2">7.2</A> <A HREF="vfs.html#toc7.2">History</A>
|
|
||||||
</H2>
|
|
||||||
|
|
||||||
<P>Original document released in June 2001 by Jason Wies.</P>
|
|
||||||
<P>Updated February 2002 to include arrayized parameters, single
|
|
||||||
quotes, and GLOBALS.</P>
|
|
||||||
<H2><A NAME="ss7.3">7.3</A> <A HREF="vfs.html#toc7.3">Contributing</A>
|
|
||||||
</H2>
|
|
||||||
|
|
||||||
maintainer, Jason Wies,
|
|
||||||
<HR>
|
|
||||||
Next
|
|
||||||
<A HREF="vfs-6.html">Previous</A>
|
|
||||||
<A HREF="vfs.html#toc7">Contents</A>
|
|
||||||
</BODY>
|
|
||||||
</HTML>
|
|
||||||
@ -1,72 +0,0 @@
|
|||||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
|
|
||||||
<HTML>
|
|
||||||
<HEAD>
|
|
||||||
<META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.17">
|
|
||||||
<TITLE>phpgwapi - VFS Class</TITLE>
|
|
||||||
<LINK HREF="vfs-1.html" REL=next>
|
|
||||||
|
|
||||||
|
|
||||||
</HEAD>
|
|
||||||
<BODY>
|
|
||||||
<A HREF="vfs-1.html">Next</A>
|
|
||||||
Previous
|
|
||||||
Contents
|
|
||||||
<HR>
|
|
||||||
<H1>phpgwapi - VFS Class</H1>
|
|
||||||
|
|
||||||
<H2>Jason Wies</H2>June 2001, February 2002
|
|
||||||
<HR>
|
|
||||||
<EM>The VFS, or Virtual File System, handles all file system activity
|
|
||||||
for eGroupWare.</EM>
|
|
||||||
<HR>
|
|
||||||
<P>
|
|
||||||
<H2><A NAME="toc1">1.</A> <A HREF="vfs-1.html">Introduction and Purpose</A></H2>
|
|
||||||
|
|
||||||
<P>
|
|
||||||
<H2><A NAME="toc2">2.</A> <A HREF="vfs-2.html">Basics</A></H2>
|
|
||||||
|
|
||||||
<UL>
|
|
||||||
<LI><A NAME="toc2.1">2.1</A> <A HREF="vfs-2.html#ss2.1">Prerequisites</A>
|
|
||||||
<LI><A NAME="toc2.2">2.2</A> <A HREF="vfs-2.html#ss2.2">Concepts</A>
|
|
||||||
</UL>
|
|
||||||
<P>
|
|
||||||
<H2><A NAME="toc3">3.</A> <A HREF="vfs-3.html">Basic Functions</A></H2>
|
|
||||||
|
|
||||||
<UL>
|
|
||||||
<LI><A NAME="toc3.1">3.1</A> <A HREF="vfs-3.html#ss3.1">path_parts ()</A>
|
|
||||||
<LI><A NAME="toc3.2">3.2</A> <A HREF="vfs-3.html#ss3.2">cd ()</A>
|
|
||||||
</UL>
|
|
||||||
<P>
|
|
||||||
<H2><A NAME="toc4">4.</A> <A HREF="vfs-4.html">Relativity</A></H2>
|
|
||||||
|
|
||||||
<UL>
|
|
||||||
<LI><A NAME="toc4.1">4.1</A> <A HREF="vfs-4.html#ss4.1">What is it and how does it work?</A>
|
|
||||||
<LI><A NAME="toc4.2">4.2</A> <A HREF="vfs-4.html#ss4.2">Complete List</A>
|
|
||||||
<LI><A NAME="toc4.3">4.3</A> <A HREF="vfs-4.html#ss4.3">Defaults</A>
|
|
||||||
</UL>
|
|
||||||
<P>
|
|
||||||
<H2><A NAME="toc5">5.</A> <A HREF="vfs-5.html">Function reference</A></H2>
|
|
||||||
|
|
||||||
<P>
|
|
||||||
<H2><A NAME="toc6">6.</A> <A HREF="vfs-6.html">Notes</A></H2>
|
|
||||||
|
|
||||||
<UL>
|
|
||||||
<LI><A NAME="toc6.1">6.1</A> <A HREF="vfs-6.html#ss6.1">Database</A>
|
|
||||||
<LI><A NAME="toc6.2">6.2</A> <A HREF="vfs-6.html#ss6.2">ACL support</A>
|
|
||||||
<LI><A NAME="toc6.3">6.3</A> <A HREF="vfs-6.html#ss6.3">Function aliases</A>
|
|
||||||
<LI><A NAME="toc6.4">6.4</A> <A HREF="vfs-6.html#ss6.4">Fakebase directory (changing /home)</A>
|
|
||||||
</UL>
|
|
||||||
<P>
|
|
||||||
<H2><A NAME="toc7">7.</A> <A HREF="vfs-7.html">About this Document</A></H2>
|
|
||||||
|
|
||||||
<UL>
|
|
||||||
<LI><A NAME="toc7.1">7.1</A> <A HREF="vfs-7.html#ss7.1">Copyright and License</A>
|
|
||||||
<LI><A NAME="toc7.2">7.2</A> <A HREF="vfs-7.html#ss7.2">History</A>
|
|
||||||
<LI><A NAME="toc7.3">7.3</A> <A HREF="vfs-7.html#ss7.3">Contributing</A>
|
|
||||||
</UL>
|
|
||||||
<HR>
|
|
||||||
<A HREF="vfs-1.html">Next</A>
|
|
||||||
Previous
|
|
||||||
Contents
|
|
||||||
</BODY>
|
|
||||||
</HTML>
|
|
||||||
File diff suppressed because it is too large
Load Diff
@ -1,648 +0,0 @@
|
|||||||
<!doctype linuxdoc system>
|
|
||||||
|
|
||||||
<article>
|
|
||||||
<!-- LyX 1.1 created this file. For more info see http://www.lyx.org/ -->
|
|
||||||
<title>
|
|
||||||
phpgwapi - VFS Class
|
|
||||||
</title>
|
|
||||||
<author>
|
|
||||||
Jason Wies
|
|
||||||
</author>
|
|
||||||
<date>
|
|
||||||
June 2001, February 2002
|
|
||||||
</date>
|
|
||||||
<abstract>
|
|
||||||
The VFS, or Virtual File System, handles all file system activity
|
|
||||||
for eGoupWare.
|
|
||||||
</abstract>
|
|
||||||
<sect>
|
|
||||||
Introduction and Purpose<label id="sec:introduction" >
|
|
||||||
<p>
|
|
||||||
The latest version of the VFS for eGoupWare combines actual
|
|
||||||
file system manipulation with fully integrated database support.
|
|
||||||
It features nearly transparent handling of files and directories,
|
|
||||||
as well as files inside and outside the virtual root. This document
|
|
||||||
is intended to provide API and application developers with a guide
|
|
||||||
to incorporating the VFS into their work.
|
|
||||||
</p>
|
|
||||||
<sect>
|
|
||||||
Basics<label id="sec:basics" >
|
|
||||||
<sect1>
|
|
||||||
Prerequisites<label id="sec:prerequisites" >
|
|
||||||
<p>
|
|
||||||
You must explicitly enable the VFS class. To do this, set 'enable_vfs_class'
|
|
||||||
to True in $GLOBALS['phpgw_info']['flags'].
|
|
||||||
An example:
|
|
||||||
</p>
|
|
||||||
<p>
|
|
||||||
<verb>
|
|
||||||
$GLOBALS['phpgw_info']['flags'] = array(
|
|
||||||
'currentapp' => 'phpwebhosting',
|
|
||||||
'noheader' => False,
|
|
||||||
'noappheader' => False,
|
|
||||||
'enable_vfs_class' => True,
|
|
||||||
'enable_browser_class' => True
|
|
||||||
);
|
|
||||||
</verb>
|
|
||||||
</p><sect1>
|
|
||||||
Concepts<label id="sec:concepts" >
|
|
||||||
<p>
|
|
||||||
The VFS in located in phpgwapi/inc/class.vfs_sql.inc.php. You
|
|
||||||
can look over it, but I don't suggest trying to understand how it
|
|
||||||
works. It isn't necessary to know its internals to use it, but you
|
|
||||||
may find the inline comments helpful. The basic things to keep in
|
|
||||||
mind:
|
|
||||||
</p>
|
|
||||||
<p>
|
|
||||||
<itemize>
|
|
||||||
<item>
|
|
||||||
Files and directories are synonymous in almost all cases
|
|
||||||
</itemize>
|
|
||||||
<p>
|
|
||||||
<verb>
|
|
||||||
$GLOBALS['phpgw']->vfs->mv (array(
|
|
||||||
'from' => 'file1',
|
|
||||||
'to' => 'dir/file2'
|
|
||||||
));
|
|
||||||
|
|
||||||
$GLOBALS['phpgw']->vfs->mv (array(
|
|
||||||
'from' => 'dir1',
|
|
||||||
'to' => 'dir/dir1'
|
|
||||||
));
|
|
||||||
|
|
||||||
$GLOBALS['phpgw']->vfs->rm (array(
|
|
||||||
'string' => 'file'
|
|
||||||
));
|
|
||||||
|
|
||||||
$GLOBALS['phpgw']->vfs->rm (array(
|
|
||||||
'string' => 'dir'
|
|
||||||
));
|
|
||||||
</verb>
|
|
||||||
</p><p>
|
|
||||||
All work as you would except them to. The major exception is:
|
|
||||||
</p>
|
|
||||||
<p>
|
|
||||||
<verb>
|
|
||||||
$GLOBALS['phpgw']->vfs->touch (array(
|
|
||||||
'string' => 'file'
|
|
||||||
));
|
|
||||||
</verb>
|
|
||||||
</p><p>
|
|
||||||
vs.
|
|
||||||
</p>
|
|
||||||
<p>
|
|
||||||
<verb>
|
|
||||||
$GLOBALS['phpgw']->vfs->mkdir (array(
|
|
||||||
'string' => 'dir'
|
|
||||||
));
|
|
||||||
|
|
||||||
</verb>
|
|
||||||
<p>
|
|
||||||
<itemize>
|
|
||||||
<item>
|
|
||||||
Users and groups are synonymous
|
|
||||||
</itemize>
|
|
||||||
</p><p>
|
|
||||||
As far as the actual paths are concerned, users and groups are
|
|
||||||
the same. /home/username works the same as /home/groupname.
|
|
||||||
</p>
|
|
||||||
<p>
|
|
||||||
<itemize>
|
|
||||||
<item>
|
|
||||||
You should never have to know the real paths of files
|
|
||||||
</itemize>
|
|
||||||
</p><p>
|
|
||||||
One of the VFS's responsibilities is to translate paths for you.
|
|
||||||
While you certainly <em>can</em> operate using full paths, it is much simpler
|
|
||||||
to use the virtual paths. For example, instead of using:
|
|
||||||
</p>
|
|
||||||
<p>
|
|
||||||
<verb>
|
|
||||||
$GLOBALS['phpgw']->vfs->cp (array(
|
|
||||||
'from' => '/var/www/egroupware/files/home/user/file1',
|
|
||||||
'to' => '/var/www/egroupware/files/home/user/file2',
|
|
||||||
'relatives' => array(
|
|
||||||
RELATIVE_NONE|VFS_REAL,
|
|
||||||
RELATIVE_NONE|VFS_REAL
|
|
||||||
)
|
|
||||||
));
|
|
||||||
</verb>
|
|
||||||
</p><p>
|
|
||||||
you might use
|
|
||||||
</p>
|
|
||||||
<p>
|
|
||||||
<verb>
|
|
||||||
$GLOBALS['phpgw']->vfs->cp (array(
|
|
||||||
'from' => '/home/user/file1',
|
|
||||||
'to' => '/home/user/file2',
|
|
||||||
'relatives' => array(
|
|
||||||
RELATIVE_NONE,
|
|
||||||
RELATIVE_NONE
|
|
||||||
)
|
|
||||||
));
|
|
||||||
</verb>
|
|
||||||
</p><p>
|
|
||||||
(We'll get to the RELATIVE's in a minute.)
|
|
||||||
</p>
|
|
||||||
<p>
|
|
||||||
Site administrators should be able to move their files dir around
|
|
||||||
on their system and know that everything will continue to work smoothly.
|
|
||||||
</p>
|
|
||||||
<p>
|
|
||||||
<itemize>
|
|
||||||
<item>
|
|
||||||
Relativity is <em>vital</em>
|
|
||||||
</itemize>
|
|
||||||
</p><p>
|
|
||||||
Relativity is a new feature in the VFS, and its importance cannot
|
|
||||||
be stressed enough. It will make your life much easier, especially
|
|
||||||
for file system intensive applications, but it will take some getting
|
|
||||||
used to. If something doesn't work right the first time, chances
|
|
||||||
are great it has to do with incorrect relativity settings. We will
|
|
||||||
deal with relativity in depth in the Relativity section.
|
|
||||||
</p>
|
|
||||||
<sect>
|
|
||||||
Basic Functions<label id="sec:basic_functions" >
|
|
||||||
<p>
|
|
||||||
These are two functions you'll need to know before we get into
|
|
||||||
relativity.
|
|
||||||
</p>
|
|
||||||
<sect1>
|
|
||||||
path_parts ()<label id="sec:path_parts" >
|
|
||||||
<p>
|
|
||||||
The job of path_parts () is to translate any given file location
|
|
||||||
into its many component parts for any relativity. The values passed
|
|
||||||
to path_parts () are:
|
|
||||||
</p>
|
|
||||||
<p>
|
|
||||||
<verb>
|
|
||||||
string
|
|
||||||
relatives
|
|
||||||
object
|
|
||||||
</verb>
|
|
||||||
</p><p>
|
|
||||||
'string' is the path you want to translate, 'relatives' is the
|
|
||||||
standard relativity array, and 'object' specifies how you would like
|
|
||||||
the return value: if 'object' is True, an object will be returned;
|
|
||||||
if 'object' is False, an array will be returned. I think you'll find
|
|
||||||
the object easier to deal with, and we'll be using it throughout
|
|
||||||
this document. The most important returned values (but not all) for
|
|
||||||
path_parts () are:
|
|
||||||
</p>
|
|
||||||
<p>
|
|
||||||
<verb>
|
|
||||||
fake_full_path
|
|
||||||
fake_leading_dirs
|
|
||||||
fake_extra_path
|
|
||||||
fake_name
|
|
||||||
real_full_path
|
|
||||||
real_leading_dirs
|
|
||||||
real_extra_path
|
|
||||||
real_name
|
|
||||||
</verb>
|
|
||||||
</p><p>
|
|
||||||
Just like you would think, fake_full_path contains the full virtual
|
|
||||||
path of 'string', and real_full_path contains the full real path
|
|
||||||
of 'string'. The fake_name and real_name variables should always
|
|
||||||
be the same, and contain the final file or directory name. The leading_dirs
|
|
||||||
contain everything except the name, and the extra_path is everything
|
|
||||||
from the / before "home" to the end of the leading_dirs. To better
|
|
||||||
illustrate, here is an example:
|
|
||||||
</p>
|
|
||||||
<p>
|
|
||||||
<verb>
|
|
||||||
$p = $GLOBALS['phpgw']->vfs->path_parts (array(
|
|
||||||
'string' => '/home/jason/dir/file',
|
|
||||||
'relatives' => array(
|
|
||||||
RELATIVE_NONE
|
|
||||||
)
|
|
||||||
));
|
|
||||||
</verb>
|
|
||||||
<p>
|
|
||||||
<itemize>
|
|
||||||
<item>
|
|
||||||
$p->fake_full_path - /home/jason/dir/file
|
|
||||||
<item>
|
|
||||||
$p->fake_leading_dirs - /home/jason/dir
|
|
||||||
<item>
|
|
||||||
$p->fake_extra_path - home/jason/dir
|
|
||||||
<item>
|
|
||||||
$p->fake_name - file
|
|
||||||
<item>
|
|
||||||
$p->real_full_path - /var/www/egroupware/files/home/jason/dir/file
|
|
||||||
<item>
|
|
||||||
$p->real_leading_dirs - /var/www/egroupware/files/home/jason/dir
|
|
||||||
|
|
||||||
<item>
|
|
||||||
$p->real_extra_path - home/jason/dir
|
|
||||||
<item>
|
|
||||||
$p->real_name - file
|
|
||||||
</itemize>
|
|
||||||
</p><p>
|
|
||||||
As you can see, path_parts () is a very useful function and will
|
|
||||||
save you from doing those darn substr ()'s yourself. For those of
|
|
||||||
you used to the prior VFS, note that <em>getabsolutepath () is depreciated</em>.
|
|
||||||
getabsolutepath () still exists (albeit in a much different form),
|
|
||||||
and is responsible for some of the path translation, but it is an
|
|
||||||
<em>internal</em> function only. Applications should only use path_parts ().
|
|
||||||
We have shown you how to use path_parts () so you can experiment
|
|
||||||
with it using different paths and relativities as we explore relativity.
|
|
||||||
</p>
|
|
||||||
<sect1>
|
|
||||||
cd ()<label id="sec:cd" >
|
|
||||||
<p>
|
|
||||||
Part of the overall goal for the VFS in eGoupWare is to give
|
|
||||||
the user a seamless experience during their session. For example,
|
|
||||||
if they upload a file using a file manager to the directory /home/my_group/project1,
|
|
||||||
and then go to download an email attachment, the default directory
|
|
||||||
will be /home/my_group/project1. This is accomplished using the cd
|
|
||||||
() function. Examples:
|
|
||||||
</p>
|
|
||||||
<p>
|
|
||||||
<verb>
|
|
||||||
/* cd to their home directory */
|
|
||||||
$GLOBALS['phpgw']->vfs->cd (array(
|
|
||||||
'string' => '/'
|
|
||||||
));
|
|
||||||
|
|
||||||
/* cd to /home/jason/dir */
|
|
||||||
$GLOBALS['phpgw']->vfs->cd (array(
|
|
||||||
'string' => '/home/jason/dir',
|
|
||||||
'relative' => False,
|
|
||||||
'relatives' => array(
|
|
||||||
RELATIVE_NONE
|
|
||||||
)
|
|
||||||
));
|
|
||||||
|
|
||||||
/* When following the above, cd's to /home/jason/dir/dir2 */
|
|
||||||
$GLOBALS['phpgw']->vfs->cd (array(
|
|
||||||
'string' => 'dir2',
|
|
||||||
'relative' => True
|
|
||||||
));
|
|
||||||
</verb>
|
|
||||||
</p><p>
|
|
||||||
If 'relative' is True, the 'string' is simply appended to the
|
|
||||||
current path. If you want to know what the current path is, use $GLOBALS['phpgw']->vfs->pwd
|
|
||||||
().
|
|
||||||
</p>
|
|
||||||
<p>
|
|
||||||
Now you're ready for relativity.
|
|
||||||
</p>
|
|
||||||
<sect>
|
|
||||||
Relativity<label id="sec:relativity" >
|
|
||||||
<p>
|
|
||||||
Ok, just one last thing before we get into relativity. You will
|
|
||||||
notice throughout the examples the use of $fakebase. $GLOBALS['phpgw']->vfs->fakebase
|
|
||||||
is by default '/home'. The old VFS was hard-coded to use '/home',
|
|
||||||
but the naming choice for this is now up to administrators. See the
|
|
||||||
<ref id="sec:fakebase" name="Fakebase directory (changing /home)" > section for more information. Throughout the rest of this document,
|
|
||||||
you will see $fakebase used in calls to the VFS, and /home
|
|
||||||
used in actual paths. <em>You should always use $fakebase when
|
|
||||||
making applications. </em>I suggest doing $fakebase = $GLOBALS['phpgw']->vfs->fakebase;
|
|
||||||
right off the bat to keep things neater.
|
|
||||||
</p>
|
|
||||||
<sect1>
|
|
||||||
What is it and how does it work?
|
|
||||||
<p>
|
|
||||||
One of the design challenges for a Virtual File System is to
|
|
||||||
try to figure out whether the calling application is referring to
|
|
||||||
a file inside or outside the virtual root, and if inside, exactly
|
|
||||||
where. To solve this problem, the eGoupWare VFS uses RELATIVE
|
|
||||||
defines that are used in bitmasks passed to each function. The result
|
|
||||||
is that any set of different relativities can be used in combination
|
|
||||||
with each other. Let's look at a few examples. Say you want to move
|
|
||||||
'logo.png' from the user's home directory to the current directory.
|
|
||||||
|
|
||||||
</p>
|
|
||||||
<p>
|
|
||||||
<verb>
|
|
||||||
$GLOBALS['phpgw']->vfs->mv (array(
|
|
||||||
'from' => 'logo.png',
|
|
||||||
'to' => 'logo.png',
|
|
||||||
'relatives' => array(
|
|
||||||
RELATIVE_USER,
|
|
||||||
RELATIVE_ALL
|
|
||||||
)
|
|
||||||
));
|
|
||||||
</verb>
|
|
||||||
</p><p>
|
|
||||||
RELATIVE_USER means relative to the user's home directory. RELATIVE_ALL
|
|
||||||
means relative to the current directory, as set by cd () and as reported
|
|
||||||
by pwd (). So if the current directory was "$fakebase/my_group/project1",
|
|
||||||
the call to mv () would be processed as:
|
|
||||||
</p>
|
|
||||||
<p>
|
|
||||||
<verb>
|
|
||||||
MOVE "$fakebase/jason/logo.png" TO "$fakebase/my_group/project1/logo.png"
|
|
||||||
</verb>
|
|
||||||
</p><p>
|
|
||||||
and the actual file system call would be:
|
|
||||||
</p>
|
|
||||||
<p>
|
|
||||||
<verb>
|
|
||||||
rename ('/var/www/egroupware/files/home/jason/logo.php', '/var/www/egroupware/files/home/my_group/project1/logo.png');
|
|
||||||
</verb>
|
|
||||||
</p><p>
|
|
||||||
Those used to the old VFS will note that you do not have to translate
|
|
||||||
the path beforehand. Let's look at another example. Suppose you were
|
|
||||||
moving an email attachment stored in eGoupWare's temporary directory
|
|
||||||
to the 'attachments' directory within the user's home directory (we're
|
|
||||||
assuming the attachments directory exists). Note that the temporary
|
|
||||||
directory is <em>outside</em> the virtual root.
|
|
||||||
</p>
|
|
||||||
<p>
|
|
||||||
<verb>
|
|
||||||
$GLOBALS['phpgw']->vfs->mv (array(
|
|
||||||
'from' => $GLOBALS['phpgw_info']['server']['temp_dir'] . '/' . $randomdir . '/' . $randomfile,
|
|
||||||
'to' => 'attachments/actual_name.ext',
|
|
||||||
'relatives' => array(
|
|
||||||
RELATIVE_NONE|VFS_REAL,
|
|
||||||
RELATIVE_USER
|
|
||||||
)
|
|
||||||
));
|
|
||||||
</verb>
|
|
||||||
</p><p>
|
|
||||||
$randomdir and $randomfile are what the directory
|
|
||||||
and file might be called before they are given a proper name by the
|
|
||||||
user, which is actual_name.ext in this example. RELATIVE_NONE is
|
|
||||||
the define for using full path names. However, RELATIVE_NONE is still
|
|
||||||
relative to the virtual root, so we pass along VFS_REAL as well,
|
|
||||||
to say that the file is <em>outside</em> the virtual root, somewhere else
|
|
||||||
in the file system. Once again, RELATIVE_USER means relative to the
|
|
||||||
user's home directory. So the actual file system call might look
|
|
||||||
like this (keep in mind that $randomdir and $randomfile
|
|
||||||
are just random strings):
|
|
||||||
</p>
|
|
||||||
<p>
|
|
||||||
<verb>
|
|
||||||
rename ('/var/www/egroupware/tmp/0ak5adftgh7/jX42sC9M', '/var/www/egroupware/files/home/jason/attachments/actual_name.ext');
|
|
||||||
</verb>
|
|
||||||
</p><p>
|
|
||||||
Of course you don't have to know that, nor should you be concerned
|
|
||||||
with it; you can take it for granted that the VFS will translate
|
|
||||||
the paths correctly. Let's take a look at one more example, this
|
|
||||||
time using the RELATIVE_USER_APP define. RELATIVE_USER_APP is used
|
|
||||||
to store quasi-hidden application files, similar to the Unix convention
|
|
||||||
of ˜/.appname. It simply appends .appname to the user's home
|
|
||||||
directory. For example, if you were making an HTML editor application
|
|
||||||
named 'htmledit', and wanted to keep a backup file in case something
|
|
||||||
goes wrong, you could use RELATIVE_USER_APP to store it:
|
|
||||||
</p>
|
|
||||||
<p>
|
|
||||||
<verb>
|
|
||||||
$GLOBALS['phpgw']->vfs->write (array(
|
|
||||||
'string' => 'file.name˜',
|
|
||||||
'relatives' => array(
|
|
||||||
RELATIVE_USER_APP
|
|
||||||
),
|
|
||||||
'content' => $contents
|
|
||||||
));
|
|
||||||
</verb>
|
|
||||||
</p><p>
|
|
||||||
This assumes that ˜/.htmledit exists of course. The backup
|
|
||||||
file "file.name˜" would then be written in $fakebase/jason/.htmledit/file.name˜.
|
|
||||||
Note that storing files like this might not be as good of a solution
|
|
||||||
as storing them in the temporary directory or in the database. But
|
|
||||||
it is there in case you need it.
|
|
||||||
</p>
|
|
||||||
<sect1>
|
|
||||||
Complete List<label id="sec:relatives_complete_list" >
|
|
||||||
<p>
|
|
||||||
Here is the complete list of RELATIVE defines, and what they
|
|
||||||
do:
|
|
||||||
</p>
|
|
||||||
<p>
|
|
||||||
<descrip>
|
|
||||||
<tag>
|
|
||||||
RELATIVE_ROOT</tag>Don't translate the path at all. Just prepends
|
|
||||||
a /. You'll probably want to use RELATIVE_NONE though, which handles
|
|
||||||
both virtual and real files.
|
|
||||||
<tag>
|
|
||||||
RELATIVE_USER</tag>User's home directory
|
|
||||||
<tag>
|
|
||||||
RELATIVE_CURR_USER</tag>Current user's home directory. If the
|
|
||||||
current directory is $fakebase/my_group/project1, this will
|
|
||||||
return is $fakebase/my_group
|
|
||||||
<tag>
|
|
||||||
RELATIVE_USER_APP</tag>Append .appname to the user's home directory,
|
|
||||||
where appname is the current application's appname
|
|
||||||
<tag>
|
|
||||||
RELATIVE_PATH</tag>DO NOT USE. Relative to the current directory,
|
|
||||||
used in RELATIVE_ALL
|
|
||||||
<tag>
|
|
||||||
RELATIVE_NONE</tag>Not relative to anything. Use this with VFS_REAL
|
|
||||||
for files outside the virtual root. Note that using RELATIVE_NONE
|
|
||||||
by itself still means relative to the virtual root
|
|
||||||
<tag>
|
|
||||||
RELATIVE_CURRENT</tag>An alias for the currently set RELATIVE
|
|
||||||
define, or RELATIVE_ALL if none is set (see the Defaults section)
|
|
||||||
<tag>
|
|
||||||
VFS_REAL</tag>File is outside of the virtual root. Usually used
|
|
||||||
with RELATIVE_NONE
|
|
||||||
<tag>
|
|
||||||
RELATIVE_ALL</tag>Relative to the current directory. Use RELATIVE_ALL<em>
|
|
||||||
</em>instead of RELATIVE_PATH
|
|
||||||
</descrip>
|
|
||||||
</p><sect1>
|
|
||||||
Defaults<label id="sec:relatives_defaults" >
|
|
||||||
<p>
|
|
||||||
You might be thinking to yourself that passing along RELATIVE
|
|
||||||
defines with every VFS call is overkill, especially if your application
|
|
||||||
always uses the same relativity. The default RELATIVE define for
|
|
||||||
all VFS calls is RELATIVE_CURRENT. RELATIVE_CURRENT itself defaults
|
|
||||||
to RELATIVE_ALL (relative to the current path), <em>unless</em> your application
|
|
||||||
sets a specific relativity. If your application requires most of
|
|
||||||
the work to be done outside of the virtual root, you may wish to
|
|
||||||
set RELATIVE_CURRENT to RELATIVE_NONE|VFS_REAL. set_relative () is
|
|
||||||
the function to do this. For example:
|
|
||||||
</p>
|
|
||||||
<p>
|
|
||||||
<verb>
|
|
||||||
$GLOBALS['phpgw']->vfs->set_relative (array(
|
|
||||||
'mask' => RELATIVE_NONE|VFS_REAL
|
|
||||||
));
|
|
||||||
|
|
||||||
$GLOBALS['phpgw']->vfs->read (array(
|
|
||||||
'string' => '/etc/passwd'
|
|
||||||
));
|
|
||||||
|
|
||||||
$GLOBALS['phpgw']->vfs->cp (array(
|
|
||||||
'from' => '/usr/include/stdio.h',
|
|
||||||
'to' => '/tmp/stdio.h'
|
|
||||||
));
|
|
||||||
|
|
||||||
$GLOBALS['phpgw']->vfs->cp (array(
|
|
||||||
'from' => '/usr/share/pixmaps/yes.xpm',
|
|
||||||
'to' => 'icons/yes.xpm',
|
|
||||||
'relatives' => array(
|
|
||||||
RELATIVE_CURRENT,
|
|
||||||
RELATIVE_USER
|
|
||||||
)
|
|
||||||
));
|
|
||||||
</verb>
|
|
||||||
</p><p>
|
|
||||||
You should notice that no relativity array is needed in the other
|
|
||||||
calls that refer to files outside the virtual root, but one is needed
|
|
||||||
for calls that include files inside the virtual root. Any RELATIVE
|
|
||||||
define can be set as the default and works in the same fashion. To
|
|
||||||
retrieve the currently set define, use get_relative (). Note that
|
|
||||||
the relativity is reset after each page request; that is, it's good
|
|
||||||
only for the life of the current page loading, and is not stored
|
|
||||||
in session management.
|
|
||||||
</p>
|
|
||||||
<sect>
|
|
||||||
Function reference<label id="sec:function_reference" >
|
|
||||||
<p>
|
|
||||||
To view the function reference for the VFS, use the doc/inlinedocparser.php
|
|
||||||
script that comes with eGoupWare, ie <url url="http://localhost/doc/inlinedocparser.php?fn=class.vfs_sql.inc.php" name="http://localhost/doc/inlinedocparser.php?fn=class.vfs_sql.inc.php">.
|
|
||||||
</p>
|
|
||||||
<sect>
|
|
||||||
Notes<label id="sec:notes" >
|
|
||||||
<sect1>
|
|
||||||
Database<label id="sec:database" >
|
|
||||||
<p>
|
|
||||||
Data about the files and directories within the virtual root
|
|
||||||
is kept in the SQL database. Currently, this information includes:
|
|
||||||
</p>
|
|
||||||
<p>
|
|
||||||
<itemize>
|
|
||||||
<item>
|
|
||||||
File ID (used internally, primary key for table)
|
|
||||||
<item>
|
|
||||||
Owner ID (phpGW account_id)
|
|
||||||
<item>
|
|
||||||
Created by ID (phpGW account_id)
|
|
||||||
<item>
|
|
||||||
Modified by ID (phpGW account_id)
|
|
||||||
<item>
|
|
||||||
Created (date)
|
|
||||||
<item>
|
|
||||||
Modified (date)
|
|
||||||
<item>
|
|
||||||
Size (bytes)
|
|
||||||
<item>
|
|
||||||
MIME type
|
|
||||||
<item>
|
|
||||||
Deleteable (Y/N/Other?)
|
|
||||||
<item>
|
|
||||||
Comment
|
|
||||||
<item>
|
|
||||||
App (appname of application that created the file)
|
|
||||||
<item>
|
|
||||||
Directory (directory the file or directory is in)
|
|
||||||
<item>
|
|
||||||
Name (name of file or directory)
|
|
||||||
<item>
|
|
||||||
Link directory (if the file or directory is linked, what the
|
|
||||||
actual directory is)
|
|
||||||
<item>
|
|
||||||
Link name (if the file or directory is linked, what the actual
|
|
||||||
name is)
|
|
||||||
<item>
|
|
||||||
Version (numeric version of the file)
|
|
||||||
</itemize>
|
|
||||||
</p><p>
|
|
||||||
The internal names of these (the database column names) are stored
|
|
||||||
in the $GLOBALS['phpgw']->vfs->attributes
|
|
||||||
array, which is useful for loops, and is guaranteed to be up-to-date.
|
|
||||||
</p>
|
|
||||||
<p>
|
|
||||||
Note that no information is kept about files outside the virtual
|
|
||||||
root. If a file is moved outside, all records of it are deleted from
|
|
||||||
the database (other than the journaling records). If a file is moved
|
|
||||||
into the virtual root, some information, specifically MIME-type,
|
|
||||||
is not always stored in the database. The vital information has defaults:
|
|
||||||
owner is based on where the file is being stored; size is correctly
|
|
||||||
read; deleteable is set to Y.
|
|
||||||
</p>
|
|
||||||
<sect1>
|
|
||||||
ACL support<label id="sec:acl_support" >
|
|
||||||
<p>
|
|
||||||
ACL support is built into the VFS. vfs->acl_check () does
|
|
||||||
the actual checking, and is called from all VFS functions as needed.
|
|
||||||
If the file or directory sent to acl_check () doesn't exist, the
|
|
||||||
permissions for the parent directory are used to determine access.
|
|
||||||
ACL checking can be overridden at any time by setting vfs->override_acl.
|
|
||||||
For example:
|
|
||||||
</p>
|
|
||||||
<p>
|
|
||||||
<verb>
|
|
||||||
$GLOBALS['phpgw']->vfs->override_acl = 1;
|
|
||||||
$GLOBALS['phpgw']->vfs->mkdir (array(
|
|
||||||
'string' => $GLOBALS['fakebase']. '/' . $group_array['account_name'],
|
|
||||||
'relatives' => array(
|
|
||||||
RELATIVE_NONE
|
|
||||||
)
|
|
||||||
));
|
|
||||||
$GLOBALS['phpgw']->vfs->override_acl = 0;
|
|
||||||
</verb>
|
|
||||||
</p><sect1>
|
|
||||||
Function aliases<label id="sec:function_aliases" >
|
|
||||||
<p>
|
|
||||||
You might have noticed there are some functions that just pass
|
|
||||||
the arguments on to other functions. These are provided in part because
|
|
||||||
of legacy and in part for convenience. You can use either. Here is
|
|
||||||
the list (alias -> actual):
|
|
||||||
</p>
|
|
||||||
<p>
|
|
||||||
<itemize>
|
|
||||||
<item>
|
|
||||||
copy -> cp
|
|
||||||
<item>
|
|
||||||
move -> rm
|
|
||||||
<item>
|
|
||||||
delete -> rm
|
|
||||||
<item>
|
|
||||||
dir -> ls
|
|
||||||
</itemize>
|
|
||||||
</p><sect1>
|
|
||||||
Fakebase directory (changing /home)<label id="sec:fakebase" >
|
|
||||||
<p>
|
|
||||||
The old VFS was hard-coded to use '/home' as the fake base directory,
|
|
||||||
even though the user never saw it. With the new system, crafty administrators
|
|
||||||
may wish to change '/home' to something else, say '/users' or '/public_html'.
|
|
||||||
The fake base directory name is stored in $GLOBALS['phpgw']->vfs->fakebase,
|
|
||||||
and changing it will transparently change it throughout the VFS and
|
|
||||||
all applications. However, this must be done <em>before</em> any data is in
|
|
||||||
the VFS database. If you wish to change it afterwords, you'll have
|
|
||||||
to manually update the database, replacing the old value with the
|
|
||||||
new value. <em>Application programmers need to recognize that /home is
|
|
||||||
not absolute, and use $GLOBALS['phpgw']->vfs->fakebase
|
|
||||||
instead</em>. I suggest setting $fakebase = $GLOBALS['phpgw']->vfs->fakebase;
|
|
||||||
right off the bat to keep things neater.
|
|
||||||
</p>
|
|
||||||
<sect>
|
|
||||||
About this Document
|
|
||||||
<sect1>
|
|
||||||
Copyright and License
|
|
||||||
<p>
|
|
||||||
Copyright (c) 2001, 2002 Jason Wies
|
|
||||||
</p>
|
|
||||||
<p>
|
|
||||||
Permission is granted to copy, distribute and/or modify this
|
|
||||||
document under the terms of the GNU Free Documentation License, Version
|
|
||||||
1.1 or any later version published by the Free Software Foundation;
|
|
||||||
with no Invarient Sections, with no Front-Cover Texts, and no Back-Cover
|
|
||||||
Texts.
|
|
||||||
</p>
|
|
||||||
<p>
|
|
||||||
A copy of the license is available at <url url="http://www.gnu.org/copyleft/fdl.html" name="http://www.gnu.org/copyleft/fdl.html">.
|
|
||||||
</p>
|
|
||||||
<sect1>
|
|
||||||
History
|
|
||||||
<p>
|
|
||||||
Original document released in June 2001 by Jason Wies.
|
|
||||||
</p>
|
|
||||||
<p>
|
|
||||||
Updated February 2002 to include arrayized parameters, single
|
|
||||||
quotes, and GLOBALS.
|
|
||||||
</p>
|
|
||||||
<sect1>
|
|
||||||
Contributing
|
|
||||||
<p>
|
|
||||||
Contributions are always welcome. Please send to the current
|
|
||||||
maintainer, Jason Wies,
|
|
||||||
</p>
|
|
||||||
|
|
||||||
|
|
||||||
</article>
|
|
||||||
@ -1,425 +0,0 @@
|
|||||||
|
|
||||||
Next Previous Contents
|
|
||||||
===============================================================================
|
|
||||||
***** 1. Introduction_and_Purpose *****
|
|
||||||
The latest version of the VFS for eGoupWare combines actual file system
|
|
||||||
manipulation with fully integrated database support. It features nearly
|
|
||||||
transparent handling of files and directories, as well as files inside and
|
|
||||||
outside the virtual root. This document is intended to provide API and
|
|
||||||
application developers with a guide to incorporating the VFS into their work.
|
|
||||||
===============================================================================
|
|
||||||
Next Previous Contents
|
|
||||||
|
|
||||||
|
|
||||||
Next Previous Contents
|
|
||||||
===============================================================================
|
|
||||||
***** 2. Basics *****
|
|
||||||
***** 2.1 Prerequisites *****
|
|
||||||
You must explicitly enable the VFS class. To do this, set 'enable_vfs_class' to
|
|
||||||
True in $GLOBALS['phpgw_info']['flags']. An example:
|
|
||||||
$GLOBALS['phpgw_info']['flags'] = array(
|
|
||||||
'currentapp' => 'phpwebhosting',
|
|
||||||
'noheader' => False,
|
|
||||||
'noappheader' => False,
|
|
||||||
'enable_vfs_class' => True,
|
|
||||||
'enable_browser_class' => True
|
|
||||||
);
|
|
||||||
***** 2.2 Concepts *****
|
|
||||||
The VFS in located in phpgwapi/inc/class.vfs_sql.inc.php. You can look over it,
|
|
||||||
but I don't suggest trying to understand how it works. It isn't necessary to
|
|
||||||
know its internals to use it, but you may find the inline comments helpful. The
|
|
||||||
basic things to keep in mind:
|
|
||||||
* Files and directories are synonymous in almost all cases
|
|
||||||
$GLOBALS['phpgw']->vfs->mv (array(
|
|
||||||
'from' => 'file1',
|
|
||||||
'to' => 'dir/file2'
|
|
||||||
));
|
|
||||||
|
|
||||||
$GLOBALS['phpgw']->vfs->mv (array(
|
|
||||||
'from' => 'dir1',
|
|
||||||
'to' => 'dir/dir1'
|
|
||||||
));
|
|
||||||
|
|
||||||
$GLOBALS['phpgw']->vfs->rm (array(
|
|
||||||
'string' => 'file'
|
|
||||||
));
|
|
||||||
|
|
||||||
$GLOBALS['phpgw']->vfs->rm (array(
|
|
||||||
'string' => 'dir'
|
|
||||||
));
|
|
||||||
All work as you would except them to. The major exception is:
|
|
||||||
$GLOBALS['phpgw']->vfs->touch (array(
|
|
||||||
'string' => 'file'
|
|
||||||
));
|
|
||||||
vs.
|
|
||||||
$GLOBALS['phpgw']->vfs->mkdir (array(
|
|
||||||
'string' => 'dir'
|
|
||||||
));
|
|
||||||
* Users and groups are synonymous
|
|
||||||
As far as the actual paths are concerned, users and groups are the same. /home/
|
|
||||||
username works the same as /home/groupname.
|
|
||||||
* You should never have to know the real paths of files
|
|
||||||
One of the VFS's responsibilities is to translate paths for you. While you
|
|
||||||
certainly can operate using full paths, it is much simpler to use the virtual
|
|
||||||
paths. For example, instead of using:
|
|
||||||
$GLOBALS['phpgw']->vfs->cp (array(
|
|
||||||
'from' => '/var/www/egroupware/files/home/user/file1',
|
|
||||||
'to' => '/var/www/egroupware/files/home/user/file2',
|
|
||||||
'relatives' => array(
|
|
||||||
RELATIVE_NONE|VFS_REAL,
|
|
||||||
RELATIVE_NONE|VFS_REAL
|
|
||||||
)
|
|
||||||
));
|
|
||||||
you might use
|
|
||||||
$GLOBALS['phpgw']->vfs->cp (array(
|
|
||||||
'from' => '/home/user/file1',
|
|
||||||
'to' => '/home/user/file2',
|
|
||||||
'relatives' => array(
|
|
||||||
RELATIVE_NONE,
|
|
||||||
RELATIVE_NONE
|
|
||||||
)
|
|
||||||
));
|
|
||||||
(We'll get to the RELATIVE's in a minute.)
|
|
||||||
Site administrators should be able to move their files dir around on their
|
|
||||||
system and know that everything will continue to work smoothly.
|
|
||||||
* Relativity is vital
|
|
||||||
Relativity is a new feature in the VFS, and its importance cannot be stressed
|
|
||||||
enough. It will make your life much easier, especially for file system
|
|
||||||
intensive applications, but it will take some getting used to. If something
|
|
||||||
doesn't work right the first time, chances are great it has to do with
|
|
||||||
incorrect relativity settings. We will deal with relativity in depth in the
|
|
||||||
Relativity section.
|
|
||||||
===============================================================================
|
|
||||||
Next Previous Contents
|
|
||||||
|
|
||||||
|
|
||||||
Next Previous Contents
|
|
||||||
===============================================================================
|
|
||||||
***** 3. Basic_Functions *****
|
|
||||||
These are two functions you'll need to know before we get into relativity.
|
|
||||||
***** 3.1 path_parts_() *****
|
|
||||||
The job of path_parts () is to translate any given file location into its many
|
|
||||||
component parts for any relativity. The values passed to path_parts () are:
|
|
||||||
string
|
|
||||||
relatives
|
|
||||||
object
|
|
||||||
'string' is the path you want to translate, 'relatives' is the standard
|
|
||||||
relativity array, and 'object' specifies how you would like the return value:
|
|
||||||
if 'object' is True, an object will be returned; if 'object' is False, an array
|
|
||||||
will be returned. I think you'll find the object easier to deal with, and we'll
|
|
||||||
be using it throughout this document. The most important returned values (but
|
|
||||||
not all) for path_parts () are:
|
|
||||||
fake_full_path
|
|
||||||
fake_leading_dirs
|
|
||||||
fake_extra_path
|
|
||||||
fake_name
|
|
||||||
real_full_path
|
|
||||||
real_leading_dirs
|
|
||||||
real_extra_path
|
|
||||||
real_name
|
|
||||||
Just like you would think, fake_full_path contains the full virtual path of
|
|
||||||
'string', and real_full_path contains the full real path of 'string'. The
|
|
||||||
fake_name and real_name variables should always be the same, and contain the
|
|
||||||
final file or directory name. The leading_dirs contain everything except the
|
|
||||||
name, and the extra_path is everything from the / before "home" to the end of
|
|
||||||
the leading_dirs. To better illustrate, here is an example:
|
|
||||||
$p = $GLOBALS['phpgw']->vfs->path_parts (array(
|
|
||||||
'string' => '/home/jason/dir/file',
|
|
||||||
'relatives' => array(
|
|
||||||
RELATIVE_NONE
|
|
||||||
)
|
|
||||||
));
|
|
||||||
* $p->fake_full_path - /home/jason/dir/file
|
|
||||||
* $p->fake_leading_dirs - /home/jason/dir
|
|
||||||
* $p->fake_extra_path - home/jason/dir
|
|
||||||
* $p->fake_name - file
|
|
||||||
* $p->real_full_path - /var/www/egroupware/files/home/jason/dir/file
|
|
||||||
* $p->real_leading_dirs - /var/www/egroupware/files/home/jason/dir
|
|
||||||
* $p->real_extra_path - home/jason/dir
|
|
||||||
* $p->real_name - file
|
|
||||||
As you can see, path_parts () is a very useful function and will save you from
|
|
||||||
doing those darn substr ()'s yourself. For those of you used to the prior VFS,
|
|
||||||
note that getabsolutepath () is depreciated. getabsolutepath () still exists
|
|
||||||
(albeit in a much different form), and is responsible for some of the path
|
|
||||||
translation, but it is an internal function only. Applications should only use
|
|
||||||
path_parts (). We have shown you how to use path_parts () so you can experiment
|
|
||||||
with it using different paths and relativities as we explore relativity.
|
|
||||||
***** 3.2 cd_() *****
|
|
||||||
Part of the overall goal for the VFS in eGoupWare is to give the user a
|
|
||||||
seamless experience during their session. For example, if they upload a file
|
|
||||||
using a file manager to the directory /home/my_group/project1, and then go to
|
|
||||||
download an email attachment, the default directory will be /home/my_group/
|
|
||||||
project1. This is accomplished using the cd () function. Examples:
|
|
||||||
/* cd to their home directory */
|
|
||||||
$GLOBALS['phpgw']->vfs->cd (array(
|
|
||||||
'string' => '/'
|
|
||||||
));
|
|
||||||
|
|
||||||
/* cd to /home/jason/dir */
|
|
||||||
$GLOBALS['phpgw']->vfs->cd (array(
|
|
||||||
'string' => '/home/jason/dir',
|
|
||||||
'relative' => False,
|
|
||||||
'relatives' => array(
|
|
||||||
RELATIVE_NONE
|
|
||||||
)
|
|
||||||
));
|
|
||||||
|
|
||||||
/* When following the above, cd's to /home/jason/dir/dir2 */
|
|
||||||
$GLOBALS['phpgw']->vfs->cd (array(
|
|
||||||
'string' => 'dir2',
|
|
||||||
'relative' => True
|
|
||||||
));
|
|
||||||
If 'relative' is True, the 'string' is simply appended to the current path. If
|
|
||||||
you want to know what the current path is, use $GLOBALS['phpgw']->vfs->pwd ().
|
|
||||||
Now you're ready for relativity.
|
|
||||||
===============================================================================
|
|
||||||
Next Previous Contents
|
|
||||||
|
|
||||||
|
|
||||||
Next Previous Contents
|
|
||||||
===============================================================================
|
|
||||||
***** 4. Relativity *****
|
|
||||||
Ok, just one last thing before we get into relativity. You will notice
|
|
||||||
throughout the examples the use of $fakebase. $GLOBALS['phpgw']->vfs->fakebase
|
|
||||||
is by default '/home'. The old VFS was hard-coded to use '/home', but the
|
|
||||||
naming choice for this is now up to administrators. See the Fakebase_directory_
|
|
||||||
(changing_/home) section for more information. Throughout the rest of this
|
|
||||||
document, you will see $fakebase used in calls to the VFS, and /home used in
|
|
||||||
actual paths. You should always use $fakebase when making applications.I
|
|
||||||
suggest doing $fakebase = $GLOBALS['phpgw']->vfs->fakebase; right off the bat
|
|
||||||
to keep things neater.
|
|
||||||
***** 4.1 What_is_it_and_how_does_it_work? *****
|
|
||||||
One of the design challenges for a Virtual File System is to try to figure out
|
|
||||||
whether the calling application is referring to a file inside or outside the
|
|
||||||
virtual root, and if inside, exactly where. To solve this problem, the
|
|
||||||
eGoupWare VFS uses RELATIVE defines that are used in bitmasks passed to each
|
|
||||||
function. The result is that any set of different relativities can be used in
|
|
||||||
combination with each other. Let's look at a few examples. Say you want to move
|
|
||||||
'logo.png' from the user's home directory to the current directory.
|
|
||||||
$GLOBALS['phpgw']->vfs->mv (array(
|
|
||||||
'from' => 'logo.png',
|
|
||||||
'to' => 'logo.png',
|
|
||||||
'relatives' => array(
|
|
||||||
RELATIVE_USER,
|
|
||||||
RELATIVE_ALL
|
|
||||||
)
|
|
||||||
));
|
|
||||||
RELATIVE_USER means relative to the user's home directory. RELATIVE_ALL means
|
|
||||||
relative to the current directory, as set by cd () and as reported by pwd ().
|
|
||||||
So if the current directory was "$fakebase/my_group/project1", the call to mv
|
|
||||||
() would be processed as:
|
|
||||||
MOVE "$fakebase/jason/logo.png" TO "$fakebase/my_group/project1/logo.png"
|
|
||||||
and the actual file system call would be:
|
|
||||||
rename ('/var/www/egroupware/files/home/jason/logo.php', '/var/www/
|
|
||||||
egroupware/files/home/my_group/project1/logo.png');
|
|
||||||
Those used to the old VFS will note that you do not have to translate the path
|
|
||||||
beforehand. Let's look at another example. Suppose you were moving an email
|
|
||||||
attachment stored in eGoupWare's temporary directory to the 'attachments'
|
|
||||||
directory within the user's home directory (we're assuming the attachments
|
|
||||||
directory exists). Note that the temporary directory is outside the virtual
|
|
||||||
root.
|
|
||||||
$GLOBALS['phpgw']->vfs->mv (array(
|
|
||||||
'from' => $GLOBALS['phpgw_info']['server']['temp_dir'] . '/' . $randomdir
|
|
||||||
. '/' . $randomfile,
|
|
||||||
'to' => 'attachments/actual_name.ext',
|
|
||||||
'relatives' => array(
|
|
||||||
RELATIVE_NONE|VFS_REAL,
|
|
||||||
RELATIVE_USER
|
|
||||||
)
|
|
||||||
));
|
|
||||||
$randomdir and $randomfile are what the directory and file might be called
|
|
||||||
before they are given a proper name by the user, which is actual_name.ext in
|
|
||||||
this example. RELATIVE_NONE is the define for using full path names. However,
|
|
||||||
RELATIVE_NONE is still relative to the virtual root, so we pass along VFS_REAL
|
|
||||||
as well, to say that the file is outside the virtual root, somewhere else in
|
|
||||||
the file system. Once again, RELATIVE_USER means relative to the user's home
|
|
||||||
directory. So the actual file system call might look like this (keep in mind
|
|
||||||
that $randomdir and $randomfile are just random strings):
|
|
||||||
rename ('/var/www/egroupware/tmp/0ak5adftgh7/jX42sC9M', '/var/www/
|
|
||||||
egroupware/files/home/jason/attachments/actual_name.ext');
|
|
||||||
Of course you don't have to know that, nor should you be concerned with it; you
|
|
||||||
can take it for granted that the VFS will translate the paths correctly. Let's
|
|
||||||
take a look at one more example, this time using the RELATIVE_USER_APP define.
|
|
||||||
RELATIVE_USER_APP is used to store quasi-hidden application files, similar to
|
|
||||||
the Unix convention of ~/.appname. It simply appends .appname to the user's
|
|
||||||
home directory. For example, if you were making an HTML editor application
|
|
||||||
named 'htmledit', and wanted to keep a backup file in case something goes
|
|
||||||
wrong, you could use RELATIVE_USER_APP to store it:
|
|
||||||
$GLOBALS['phpgw']->vfs->write (array(
|
|
||||||
'string' => 'file.name~',
|
|
||||||
'relatives' => array(
|
|
||||||
RELATIVE_USER_APP
|
|
||||||
),
|
|
||||||
'content' => $contents
|
|
||||||
));
|
|
||||||
This assumes that ~/.htmledit exists of course. The backup file "file.name~"
|
|
||||||
would then be written in $fakebase/jason/.htmledit/file.name~. Note that
|
|
||||||
storing files like this might not be as good of a solution as storing them in
|
|
||||||
the temporary directory or in the database. But it is there in case you need
|
|
||||||
it.
|
|
||||||
***** 4.2 Complete_List *****
|
|
||||||
Here is the complete list of RELATIVE defines, and what they do:
|
|
||||||
RELATIVE_ROOT
|
|
||||||
Don't translate the path at all. Just prepends a /. You'll probably want
|
|
||||||
to use RELATIVE_NONE though, which handles both virtual and real files.
|
|
||||||
RELATIVE_USER
|
|
||||||
User's home directory
|
|
||||||
RELATIVE_CURR_USER
|
|
||||||
Current user's home directory. If the current directory is $fakebase/
|
|
||||||
my_group/project1, this will return is $fakebase/my_group
|
|
||||||
RELATIVE_USER_APP
|
|
||||||
Append .appname to the user's home directory, where appname is the
|
|
||||||
current application's appname
|
|
||||||
RELATIVE_PATH
|
|
||||||
DO NOT USE. Relative to the current directory, used in RELATIVE_ALL
|
|
||||||
RELATIVE_NONE
|
|
||||||
Not relative to anything. Use this with VFS_REAL for files outside the
|
|
||||||
virtual root. Note that using RELATIVE_NONE by itself still means
|
|
||||||
relative to the virtual root
|
|
||||||
RELATIVE_CURRENT
|
|
||||||
An alias for the currently set RELATIVE define, or RELATIVE_ALL if none
|
|
||||||
is set (see the Defaults section)
|
|
||||||
VFS_REAL
|
|
||||||
File is outside of the virtual root. Usually used with RELATIVE_NONE
|
|
||||||
RELATIVE_ALL
|
|
||||||
Relative to the current directory. Use RELATIVE_ALLinstead of
|
|
||||||
RELATIVE_PATH
|
|
||||||
***** 4.3 Defaults *****
|
|
||||||
You might be thinking to yourself that passing along RELATIVE defines with
|
|
||||||
every VFS call is overkill, especially if your application always uses the same
|
|
||||||
relativity. The default RELATIVE define for all VFS calls is RELATIVE_CURRENT.
|
|
||||||
RELATIVE_CURRENT itself defaults to RELATIVE_ALL (relative to the current
|
|
||||||
path), unless your application sets a specific relativity. If your application
|
|
||||||
requires most of the work to be done outside of the virtual root, you may wish
|
|
||||||
to set RELATIVE_CURRENT to RELATIVE_NONE|VFS_REAL. set_relative () is the
|
|
||||||
function to do this. For example:
|
|
||||||
$GLOBALS['phpgw']->vfs->set_relative (array(
|
|
||||||
'mask' => RELATIVE_NONE|VFS_REAL
|
|
||||||
));
|
|
||||||
|
|
||||||
$GLOBALS['phpgw']->vfs->read (array(
|
|
||||||
'string' => '/etc/passwd'
|
|
||||||
));
|
|
||||||
|
|
||||||
$GLOBALS['phpgw']->vfs->cp (array(
|
|
||||||
'from' => '/usr/include/stdio.h',
|
|
||||||
'to' => '/tmp/stdio.h'
|
|
||||||
));
|
|
||||||
|
|
||||||
$GLOBALS['phpgw']->vfs->cp (array(
|
|
||||||
'from' => '/usr/share/pixmaps/yes.xpm',
|
|
||||||
'to' => 'icons/yes.xpm',
|
|
||||||
'relatives' => array(
|
|
||||||
RELATIVE_CURRENT,
|
|
||||||
RELATIVE_USER
|
|
||||||
)
|
|
||||||
));
|
|
||||||
You should notice that no relativity array is needed in the other calls that
|
|
||||||
refer to files outside the virtual root, but one is needed for calls that
|
|
||||||
include files inside the virtual root. Any RELATIVE define can be set as the
|
|
||||||
default and works in the same fashion. To retrieve the currently set define,
|
|
||||||
use get_relative (). Note that the relativity is reset after each page request;
|
|
||||||
that is, it's good only for the life of the current page loading, and is not
|
|
||||||
stored in session management.
|
|
||||||
===============================================================================
|
|
||||||
Next Previous Contents
|
|
||||||
|
|
||||||
|
|
||||||
Next Previous Contents
|
|
||||||
===============================================================================
|
|
||||||
***** 5. Function_reference *****
|
|
||||||
To view the function reference for the VFS, use the doc/inlinedocparser.php
|
|
||||||
script that comes with eGoupWare, ie http://localhost/doc/
|
|
||||||
inlinedocparser.php?fn=class.vfs_sql.inc.php.
|
|
||||||
===============================================================================
|
|
||||||
Next Previous Contents
|
|
||||||
|
|
||||||
|
|
||||||
Next Previous Contents
|
|
||||||
===============================================================================
|
|
||||||
***** 6. Notes *****
|
|
||||||
***** 6.1 Database *****
|
|
||||||
Data about the files and directories within the virtual root is kept in the SQL
|
|
||||||
database. Currently, this information includes:
|
|
||||||
* File ID (used internally, primary key for table)
|
|
||||||
* Owner ID (phpGW account_id)
|
|
||||||
* Created by ID (phpGW account_id)
|
|
||||||
* Modified by ID (phpGW account_id)
|
|
||||||
* Created (date)
|
|
||||||
* Modified (date)
|
|
||||||
* Size (bytes)
|
|
||||||
* MIME type
|
|
||||||
* Deleteable (Y/N/Other?)
|
|
||||||
* Comment
|
|
||||||
* App (appname of application that created the file)
|
|
||||||
* Directory (directory the file or directory is in)
|
|
||||||
* Name (name of file or directory)
|
|
||||||
* Link directory (if the file or directory is linked, what the actual
|
|
||||||
directory is)
|
|
||||||
* Link name (if the file or directory is linked, what the actual name is)
|
|
||||||
* Version (numeric version of the file)
|
|
||||||
The internal names of these (the database column names) are stored in the
|
|
||||||
$GLOBALS['phpgw']->vfs->attributes array, which is useful for loops, and is
|
|
||||||
guaranteed to be up-to-date.
|
|
||||||
Note that no information is kept about files outside the virtual root. If a
|
|
||||||
file is moved outside, all records of it are deleted from the database (other
|
|
||||||
than the journaling records). If a file is moved into the virtual root, some
|
|
||||||
information, specifically MIME-type, is not always stored in the database. The
|
|
||||||
vital information has defaults: owner is based on where the file is being
|
|
||||||
stored; size is correctly read; deleteable is set to Y.
|
|
||||||
***** 6.2 ACL_support *****
|
|
||||||
ACL support is built into the VFS. vfs->acl_check () does the actual checking,
|
|
||||||
and is called from all VFS functions as needed. If the file or directory sent
|
|
||||||
to acl_check () doesn't exist, the permissions for the parent directory are
|
|
||||||
used to determine access. ACL checking can be overridden at any time by setting
|
|
||||||
vfs->override_acl. For example:
|
|
||||||
$GLOBALS['phpgw']->vfs->override_acl = 1;
|
|
||||||
$GLOBALS['phpgw']->vfs->mkdir (array(
|
|
||||||
'string' => $GLOBALS['fakebase']. '/' . $group_array['account_name'],
|
|
||||||
'relatives' => array(
|
|
||||||
RELATIVE_NONE
|
|
||||||
)
|
|
||||||
));
|
|
||||||
$GLOBALS['phpgw']->vfs->override_acl = 0;
|
|
||||||
***** 6.3 Function_aliases *****
|
|
||||||
You might have noticed there are some functions that just pass the arguments on
|
|
||||||
to other functions. These are provided in part because of legacy and in part
|
|
||||||
for convenience. You can use either. Here is the list (alias -> actual):
|
|
||||||
* copy -> cp
|
|
||||||
* move -> rm
|
|
||||||
* delete -> rm
|
|
||||||
* dir -> ls
|
|
||||||
***** 6.4 Fakebase_directory_(changing_/home) *****
|
|
||||||
The old VFS was hard-coded to use '/home' as the fake base directory, even
|
|
||||||
though the user never saw it. With the new system, crafty administrators may
|
|
||||||
wish to change '/home' to something else, say '/users' or '/public_html'. The
|
|
||||||
fake base directory name is stored in $GLOBALS['phpgw']->vfs->fakebase, and
|
|
||||||
changing it will transparently change it throughout the VFS and all
|
|
||||||
applications. However, this must be done before any data is in the VFS
|
|
||||||
database. If you wish to change it afterwords, you'll have to manually update
|
|
||||||
the database, replacing the old value with the new value. Application
|
|
||||||
programmers need to recognize that /home is not absolute, and use $GLOBALS
|
|
||||||
['phpgw']->vfs->fakebase instead. I suggest setting $fakebase = $GLOBALS
|
|
||||||
['phpgw']->vfs->fakebase; right off the bat to keep things neater.
|
|
||||||
===============================================================================
|
|
||||||
Next Previous Contents
|
|
||||||
|
|
||||||
Next Previous Contents
|
|
||||||
===============================================================================
|
|
||||||
***** 7. About_this_Document *****
|
|
||||||
***** 7.1 Copyright_and_License *****
|
|
||||||
Copyright (c) 2001, 2002 Jason Wies
|
|
||||||
Permission is granted to copy, distribute and/or modify this document under the
|
|
||||||
terms of the GNU Free Documentation License, Version 1.1 or any later version
|
|
||||||
published by the Free Software Foundation; with no Invarient Sections, with no
|
|
||||||
Front-Cover Texts, and no Back-Cover Texts.
|
|
||||||
A copy of the license is available at http://www.gnu.org/copyleft/fdl.html.
|
|
||||||
***** 7.2 History *****
|
|
||||||
Original document released in June 2001 by Jason Wies.
|
|
||||||
Updated February 2002 to include arrayized parameters, single quotes, and
|
|
||||||
GLOBALS.
|
|
||||||
***** 7.3 Contributing *****
|
|
||||||
Contributions are always welcome. Please send to the current maintainer, Jason
|
|
||||||
Wies,
|
|
||||||
===============================================================================
|
|
||||||
Next Previous Contents
|
|
||||||
Loading…
Reference in New Issue
Block a user