1 | <!doctype linuxdoc system> |
---|
2 | |
---|
3 | <article> |
---|
4 | <!-- LyX 1.1 created this file. For more info see http://www.lyx.org/ --> |
---|
5 | <title> |
---|
6 | phpgwapi - VFS Class |
---|
7 | </title> |
---|
8 | <author> |
---|
9 | Jason Wies |
---|
10 | </author> |
---|
11 | <date> |
---|
12 | June 2001, February 2002 |
---|
13 | </date> |
---|
14 | <abstract> |
---|
15 | The VFS, or Virtual File System, handles all file system activity |
---|
16 | for eGoupWare. |
---|
17 | </abstract> |
---|
18 | <sect> |
---|
19 | Introduction and Purpose<label id="sec:introduction" > |
---|
20 | <p> |
---|
21 | The latest version of the VFS for eGoupWare combines actual |
---|
22 | file system manipulation with fully integrated database support. |
---|
23 | It features nearly transparent handling of files and directories, |
---|
24 | as well as files inside and outside the virtual root. This document |
---|
25 | is intended to provide API and application developers with a guide |
---|
26 | to incorporating the VFS into their work. |
---|
27 | </p> |
---|
28 | <sect> |
---|
29 | Basics<label id="sec:basics" > |
---|
30 | <sect1> |
---|
31 | Prerequisites<label id="sec:prerequisites" > |
---|
32 | <p> |
---|
33 | You must explicitly enable the VFS class. To do this, set 'enable_vfs_class' |
---|
34 | to True in $GLOBALS['phpgw_info']['flags']. |
---|
35 | An example: |
---|
36 | </p> |
---|
37 | <p> |
---|
38 | <verb> |
---|
39 | $GLOBALS['phpgw_info']['flags'] = array( |
---|
40 | 'currentapp' => 'phpwebhosting', |
---|
41 | 'noheader' => False, |
---|
42 | 'noappheader' => False, |
---|
43 | 'enable_vfs_class' => True, |
---|
44 | 'enable_browser_class' => True |
---|
45 | ); |
---|
46 | </verb> |
---|
47 | </p><sect1> |
---|
48 | Concepts<label id="sec:concepts" > |
---|
49 | <p> |
---|
50 | The VFS in located in phpgwapi/inc/class.vfs_sql.inc.php. You |
---|
51 | can look over it, but I don't suggest trying to understand how it |
---|
52 | works. It isn't necessary to know its internals to use it, but you |
---|
53 | may find the inline comments helpful. The basic things to keep in |
---|
54 | mind: |
---|
55 | </p> |
---|
56 | <p> |
---|
57 | <itemize> |
---|
58 | <item> |
---|
59 | Files and directories are synonymous in almost all cases |
---|
60 | </itemize> |
---|
61 | <p> |
---|
62 | <verb> |
---|
63 | $GLOBALS['phpgw']->vfs->mv (array( |
---|
64 | 'from' => 'file1', |
---|
65 | 'to' => 'dir/file2' |
---|
66 | )); |
---|
67 | |
---|
68 | $GLOBALS['phpgw']->vfs->mv (array( |
---|
69 | 'from' => 'dir1', |
---|
70 | 'to' => 'dir/dir1' |
---|
71 | )); |
---|
72 | |
---|
73 | $GLOBALS['phpgw']->vfs->rm (array( |
---|
74 | 'string' => 'file' |
---|
75 | )); |
---|
76 | |
---|
77 | $GLOBALS['phpgw']->vfs->rm (array( |
---|
78 | 'string' => 'dir' |
---|
79 | )); |
---|
80 | </verb> |
---|
81 | </p><p> |
---|
82 | All work as you would except them to. The major exception is: |
---|
83 | </p> |
---|
84 | <p> |
---|
85 | <verb> |
---|
86 | $GLOBALS['phpgw']->vfs->touch (array( |
---|
87 | 'string' => 'file' |
---|
88 | )); |
---|
89 | </verb> |
---|
90 | </p><p> |
---|
91 | vs. |
---|
92 | </p> |
---|
93 | <p> |
---|
94 | <verb> |
---|
95 | $GLOBALS['phpgw']->vfs->mkdir (array( |
---|
96 | 'string' => 'dir' |
---|
97 | )); |
---|
98 | |
---|
99 | </verb> |
---|
100 | <p> |
---|
101 | <itemize> |
---|
102 | <item> |
---|
103 | Users and groups are synonymous |
---|
104 | </itemize> |
---|
105 | </p><p> |
---|
106 | As far as the actual paths are concerned, users and groups are |
---|
107 | the same. /home/username works the same as /home/groupname. |
---|
108 | </p> |
---|
109 | <p> |
---|
110 | <itemize> |
---|
111 | <item> |
---|
112 | You should never have to know the real paths of files |
---|
113 | </itemize> |
---|
114 | </p><p> |
---|
115 | One of the VFS's responsibilities is to translate paths for you. |
---|
116 | While you certainly <em>can</em> operate using full paths, it is much simpler |
---|
117 | to use the virtual paths. For example, instead of using: |
---|
118 | </p> |
---|
119 | <p> |
---|
120 | <verb> |
---|
121 | $GLOBALS['phpgw']->vfs->cp (array( |
---|
122 | 'from' => '/var/www/egroupware/files/home/user/file1', |
---|
123 | 'to' => '/var/www/egroupware/files/home/user/file2', |
---|
124 | 'relatives' => array( |
---|
125 | RELATIVE_NONE|VFS_REAL, |
---|
126 | RELATIVE_NONE|VFS_REAL |
---|
127 | ) |
---|
128 | )); |
---|
129 | </verb> |
---|
130 | </p><p> |
---|
131 | you might use |
---|
132 | </p> |
---|
133 | <p> |
---|
134 | <verb> |
---|
135 | $GLOBALS['phpgw']->vfs->cp (array( |
---|
136 | 'from' => '/home/user/file1', |
---|
137 | 'to' => '/home/user/file2', |
---|
138 | 'relatives' => array( |
---|
139 | RELATIVE_NONE, |
---|
140 | RELATIVE_NONE |
---|
141 | ) |
---|
142 | )); |
---|
143 | </verb> |
---|
144 | </p><p> |
---|
145 | (We'll get to the RELATIVE's in a minute.) |
---|
146 | </p> |
---|
147 | <p> |
---|
148 | Site administrators should be able to move their files dir around |
---|
149 | on their system and know that everything will continue to work smoothly. |
---|
150 | </p> |
---|
151 | <p> |
---|
152 | <itemize> |
---|
153 | <item> |
---|
154 | Relativity is <em>vital</em> |
---|
155 | </itemize> |
---|
156 | </p><p> |
---|
157 | Relativity is a new feature in the VFS, and its importance cannot |
---|
158 | be stressed enough. It will make your life much easier, especially |
---|
159 | for file system intensive applications, but it will take some getting |
---|
160 | used to. If something doesn't work right the first time, chances |
---|
161 | are great it has to do with incorrect relativity settings. We will |
---|
162 | deal with relativity in depth in the Relativity section. |
---|
163 | </p> |
---|
164 | <sect> |
---|
165 | Basic Functions<label id="sec:basic_functions" > |
---|
166 | <p> |
---|
167 | These are two functions you'll need to know before we get into |
---|
168 | relativity. |
---|
169 | </p> |
---|
170 | <sect1> |
---|
171 | path_parts ()<label id="sec:path_parts" > |
---|
172 | <p> |
---|
173 | The job of path_parts () is to translate any given file location |
---|
174 | into its many component parts for any relativity. The values passed |
---|
175 | to path_parts () are: |
---|
176 | </p> |
---|
177 | <p> |
---|
178 | <verb> |
---|
179 | string |
---|
180 | relatives |
---|
181 | object |
---|
182 | </verb> |
---|
183 | </p><p> |
---|
184 | 'string' is the path you want to translate, 'relatives' is the |
---|
185 | standard relativity array, and 'object' specifies how you would like |
---|
186 | the return value: if 'object' is True, an object will be returned; |
---|
187 | if 'object' is False, an array will be returned. I think you'll find |
---|
188 | the object easier to deal with, and we'll be using it throughout |
---|
189 | this document. The most important returned values (but not all) for |
---|
190 | path_parts () are: |
---|
191 | </p> |
---|
192 | <p> |
---|
193 | <verb> |
---|
194 | fake_full_path |
---|
195 | fake_leading_dirs |
---|
196 | fake_extra_path |
---|
197 | fake_name |
---|
198 | real_full_path |
---|
199 | real_leading_dirs |
---|
200 | real_extra_path |
---|
201 | real_name |
---|
202 | </verb> |
---|
203 | </p><p> |
---|
204 | Just like you would think, fake_full_path contains the full virtual |
---|
205 | path of 'string', and real_full_path contains the full real path |
---|
206 | of 'string'. The fake_name and real_name variables should always |
---|
207 | be the same, and contain the final file or directory name. The leading_dirs |
---|
208 | contain everything except the name, and the extra_path is everything |
---|
209 | from the / before "home" to the end of the leading_dirs. To better |
---|
210 | illustrate, here is an example: |
---|
211 | </p> |
---|
212 | <p> |
---|
213 | <verb> |
---|
214 | $p = $GLOBALS['phpgw']->vfs->path_parts (array( |
---|
215 | 'string' => '/home/jason/dir/file', |
---|
216 | 'relatives' => array( |
---|
217 | RELATIVE_NONE |
---|
218 | ) |
---|
219 | )); |
---|
220 | </verb> |
---|
221 | <p> |
---|
222 | <itemize> |
---|
223 | <item> |
---|
224 | $p->fake_full_path - /home/jason/dir/file |
---|
225 | <item> |
---|
226 | $p->fake_leading_dirs - /home/jason/dir |
---|
227 | <item> |
---|
228 | $p->fake_extra_path - home/jason/dir |
---|
229 | <item> |
---|
230 | $p->fake_name - file |
---|
231 | <item> |
---|
232 | $p->real_full_path - /var/www/egroupware/files/home/jason/dir/file |
---|
233 | <item> |
---|
234 | $p->real_leading_dirs - /var/www/egroupware/files/home/jason/dir |
---|
235 | |
---|
236 | <item> |
---|
237 | $p->real_extra_path - home/jason/dir |
---|
238 | <item> |
---|
239 | $p->real_name - file |
---|
240 | </itemize> |
---|
241 | </p><p> |
---|
242 | As you can see, path_parts () is a very useful function and will |
---|
243 | save you from doing those darn substr ()'s yourself. For those of |
---|
244 | you used to the prior VFS, note that <em>getabsolutepath () is depreciated</em>. |
---|
245 | getabsolutepath () still exists (albeit in a much different form), |
---|
246 | and is responsible for some of the path translation, but it is an |
---|
247 | <em>internal</em> function only. Applications should only use path_parts (). |
---|
248 | We have shown you how to use path_parts () so you can experiment |
---|
249 | with it using different paths and relativities as we explore relativity. |
---|
250 | </p> |
---|
251 | <sect1> |
---|
252 | cd ()<label id="sec:cd" > |
---|
253 | <p> |
---|
254 | Part of the overall goal for the VFS in eGoupWare is to give |
---|
255 | the user a seamless experience during their session. For example, |
---|
256 | if they upload a file using a file manager to the directory /home/my_group/project1, |
---|
257 | and then go to download an email attachment, the default directory |
---|
258 | will be /home/my_group/project1. This is accomplished using the cd |
---|
259 | () function. Examples: |
---|
260 | </p> |
---|
261 | <p> |
---|
262 | <verb> |
---|
263 | /* cd to their home directory */ |
---|
264 | $GLOBALS['phpgw']->vfs->cd (array( |
---|
265 | 'string' => '/' |
---|
266 | )); |
---|
267 | |
---|
268 | /* cd to /home/jason/dir */ |
---|
269 | $GLOBALS['phpgw']->vfs->cd (array( |
---|
270 | 'string' => '/home/jason/dir', |
---|
271 | 'relative' => False, |
---|
272 | 'relatives' => array( |
---|
273 | RELATIVE_NONE |
---|
274 | ) |
---|
275 | )); |
---|
276 | |
---|
277 | /* When following the above, cd's to /home/jason/dir/dir2 */ |
---|
278 | $GLOBALS['phpgw']->vfs->cd (array( |
---|
279 | 'string' => 'dir2', |
---|
280 | 'relative' => True |
---|
281 | )); |
---|
282 | </verb> |
---|
283 | </p><p> |
---|
284 | If 'relative' is True, the 'string' is simply appended to the |
---|
285 | current path. If you want to know what the current path is, use $GLOBALS['phpgw']->vfs->pwd |
---|
286 | (). |
---|
287 | </p> |
---|
288 | <p> |
---|
289 | Now you're ready for relativity. |
---|
290 | </p> |
---|
291 | <sect> |
---|
292 | Relativity<label id="sec:relativity" > |
---|
293 | <p> |
---|
294 | Ok, just one last thing before we get into relativity. You will |
---|
295 | notice throughout the examples the use of $fakebase. $GLOBALS['phpgw']->vfs->fakebase |
---|
296 | is by default '/home'. The old VFS was hard-coded to use '/home', |
---|
297 | but the naming choice for this is now up to administrators. See the |
---|
298 | <ref id="sec:fakebase" name="Fakebase directory (changing /home)" > section for more information. Throughout the rest of this document, |
---|
299 | you will see $fakebase used in calls to the VFS, and /home |
---|
300 | used in actual paths. <em>You should always use $fakebase when |
---|
301 | making applications. </em>I suggest doing $fakebase = $GLOBALS['phpgw']->vfs->fakebase; |
---|
302 | right off the bat to keep things neater. |
---|
303 | </p> |
---|
304 | <sect1> |
---|
305 | What is it and how does it work? |
---|
306 | <p> |
---|
307 | One of the design challenges for a Virtual File System is to |
---|
308 | try to figure out whether the calling application is referring to |
---|
309 | a file inside or outside the virtual root, and if inside, exactly |
---|
310 | where. To solve this problem, the eGoupWare VFS uses RELATIVE |
---|
311 | defines that are used in bitmasks passed to each function. The result |
---|
312 | is that any set of different relativities can be used in combination |
---|
313 | with each other. Let's look at a few examples. Say you want to move |
---|
314 | 'logo.png' from the user's home directory to the current directory. |
---|
315 | |
---|
316 | </p> |
---|
317 | <p> |
---|
318 | <verb> |
---|
319 | $GLOBALS['phpgw']->vfs->mv (array( |
---|
320 | 'from' => 'logo.png', |
---|
321 | 'to' => 'logo.png', |
---|
322 | 'relatives' => array( |
---|
323 | RELATIVE_USER, |
---|
324 | RELATIVE_ALL |
---|
325 | ) |
---|
326 | )); |
---|
327 | </verb> |
---|
328 | </p><p> |
---|
329 | RELATIVE_USER means relative to the user's home directory. RELATIVE_ALL |
---|
330 | means relative to the current directory, as set by cd () and as reported |
---|
331 | by pwd (). So if the current directory was "$fakebase/my_group/project1", |
---|
332 | the call to mv () would be processed as: |
---|
333 | </p> |
---|
334 | <p> |
---|
335 | <verb> |
---|
336 | MOVE "$fakebase/jason/logo.png" TO "$fakebase/my_group/project1/logo.png" |
---|
337 | </verb> |
---|
338 | </p><p> |
---|
339 | and the actual file system call would be: |
---|
340 | </p> |
---|
341 | <p> |
---|
342 | <verb> |
---|
343 | rename ('/var/www/egroupware/files/home/jason/logo.php', '/var/www/egroupware/files/home/my_group/project1/logo.png'); |
---|
344 | </verb> |
---|
345 | </p><p> |
---|
346 | Those used to the old VFS will note that you do not have to translate |
---|
347 | the path beforehand. Let's look at another example. Suppose you were |
---|
348 | moving an email attachment stored in eGoupWare's temporary directory |
---|
349 | to the 'attachments' directory within the user's home directory (we're |
---|
350 | assuming the attachments directory exists). Note that the temporary |
---|
351 | directory is <em>outside</em> the virtual root. |
---|
352 | </p> |
---|
353 | <p> |
---|
354 | <verb> |
---|
355 | $GLOBALS['phpgw']->vfs->mv (array( |
---|
356 | 'from' => $GLOBALS['phpgw_info']['server']['temp_dir'] . '/' . $randomdir . '/' . $randomfile, |
---|
357 | 'to' => 'attachments/actual_name.ext', |
---|
358 | 'relatives' => array( |
---|
359 | RELATIVE_NONE|VFS_REAL, |
---|
360 | RELATIVE_USER |
---|
361 | ) |
---|
362 | )); |
---|
363 | </verb> |
---|
364 | </p><p> |
---|
365 | $randomdir and $randomfile are what the directory |
---|
366 | and file might be called before they are given a proper name by the |
---|
367 | user, which is actual_name.ext in this example. RELATIVE_NONE is |
---|
368 | the define for using full path names. However, RELATIVE_NONE is still |
---|
369 | relative to the virtual root, so we pass along VFS_REAL as well, |
---|
370 | to say that the file is <em>outside</em> the virtual root, somewhere else |
---|
371 | in the file system. Once again, RELATIVE_USER means relative to the |
---|
372 | user's home directory. So the actual file system call might look |
---|
373 | like this (keep in mind that $randomdir and $randomfile |
---|
374 | are just random strings): |
---|
375 | </p> |
---|
376 | <p> |
---|
377 | <verb> |
---|
378 | rename ('/var/www/egroupware/tmp/0ak5adftgh7/jX42sC9M', '/var/www/egroupware/files/home/jason/attachments/actual_name.ext'); |
---|
379 | </verb> |
---|
380 | </p><p> |
---|
381 | Of course you don't have to know that, nor should you be concerned |
---|
382 | with it; you can take it for granted that the VFS will translate |
---|
383 | the paths correctly. Let's take a look at one more example, this |
---|
384 | time using the RELATIVE_USER_APP define. RELATIVE_USER_APP is used |
---|
385 | to store quasi-hidden application files, similar to the Unix convention |
---|
386 | of ˜/.appname. It simply appends .appname to the user's home |
---|
387 | directory. For example, if you were making an HTML editor application |
---|
388 | named 'htmledit', and wanted to keep a backup file in case something |
---|
389 | goes wrong, you could use RELATIVE_USER_APP to store it: |
---|
390 | </p> |
---|
391 | <p> |
---|
392 | <verb> |
---|
393 | $GLOBALS['phpgw']->vfs->write (array( |
---|
394 | 'string' => 'file.name˜', |
---|
395 | 'relatives' => array( |
---|
396 | RELATIVE_USER_APP |
---|
397 | ), |
---|
398 | 'content' => $contents |
---|
399 | )); |
---|
400 | </verb> |
---|
401 | </p><p> |
---|
402 | This assumes that ˜/.htmledit exists of course. The backup |
---|
403 | file "file.name˜" would then be written in $fakebase/jason/.htmledit/file.name˜. |
---|
404 | Note that storing files like this might not be as good of a solution |
---|
405 | as storing them in the temporary directory or in the database. But |
---|
406 | it is there in case you need it. |
---|
407 | </p> |
---|
408 | <sect1> |
---|
409 | Complete List<label id="sec:relatives_complete_list" > |
---|
410 | <p> |
---|
411 | Here is the complete list of RELATIVE defines, and what they |
---|
412 | do: |
---|
413 | </p> |
---|
414 | <p> |
---|
415 | <descrip> |
---|
416 | <tag> |
---|
417 | RELATIVE_ROOT</tag>Don't translate the path at all. Just prepends |
---|
418 | a /. You'll probably want to use RELATIVE_NONE though, which handles |
---|
419 | both virtual and real files. |
---|
420 | <tag> |
---|
421 | RELATIVE_USER</tag>User's home directory |
---|
422 | <tag> |
---|
423 | RELATIVE_CURR_USER</tag>Current user's home directory. If the |
---|
424 | current directory is $fakebase/my_group/project1, this will |
---|
425 | return is $fakebase/my_group |
---|
426 | <tag> |
---|
427 | RELATIVE_USER_APP</tag>Append .appname to the user's home directory, |
---|
428 | where appname is the current application's appname |
---|
429 | <tag> |
---|
430 | RELATIVE_PATH</tag>DO NOT USE. Relative to the current directory, |
---|
431 | used in RELATIVE_ALL |
---|
432 | <tag> |
---|
433 | RELATIVE_NONE</tag>Not relative to anything. Use this with VFS_REAL |
---|
434 | for files outside the virtual root. Note that using RELATIVE_NONE |
---|
435 | by itself still means relative to the virtual root |
---|
436 | <tag> |
---|
437 | RELATIVE_CURRENT</tag>An alias for the currently set RELATIVE |
---|
438 | define, or RELATIVE_ALL if none is set (see the Defaults section) |
---|
439 | <tag> |
---|
440 | VFS_REAL</tag>File is outside of the virtual root. Usually used |
---|
441 | with RELATIVE_NONE |
---|
442 | <tag> |
---|
443 | RELATIVE_ALL</tag>Relative to the current directory. Use RELATIVE_ALL<em> |
---|
444 | </em>instead of RELATIVE_PATH |
---|
445 | </descrip> |
---|
446 | </p><sect1> |
---|
447 | Defaults<label id="sec:relatives_defaults" > |
---|
448 | <p> |
---|
449 | You might be thinking to yourself that passing along RELATIVE |
---|
450 | defines with every VFS call is overkill, especially if your application |
---|
451 | always uses the same relativity. The default RELATIVE define for |
---|
452 | all VFS calls is RELATIVE_CURRENT. RELATIVE_CURRENT itself defaults |
---|
453 | to RELATIVE_ALL (relative to the current path), <em>unless</em> your application |
---|
454 | sets a specific relativity. If your application requires most of |
---|
455 | the work to be done outside of the virtual root, you may wish to |
---|
456 | set RELATIVE_CURRENT to RELATIVE_NONE|VFS_REAL. set_relative () is |
---|
457 | the function to do this. For example: |
---|
458 | </p> |
---|
459 | <p> |
---|
460 | <verb> |
---|
461 | $GLOBALS['phpgw']->vfs->set_relative (array( |
---|
462 | 'mask' => RELATIVE_NONE|VFS_REAL |
---|
463 | )); |
---|
464 | |
---|
465 | $GLOBALS['phpgw']->vfs->read (array( |
---|
466 | 'string' => '/etc/passwd' |
---|
467 | )); |
---|
468 | |
---|
469 | $GLOBALS['phpgw']->vfs->cp (array( |
---|
470 | 'from' => '/usr/include/stdio.h', |
---|
471 | 'to' => '/tmp/stdio.h' |
---|
472 | )); |
---|
473 | |
---|
474 | $GLOBALS['phpgw']->vfs->cp (array( |
---|
475 | 'from' => '/usr/share/pixmaps/yes.xpm', |
---|
476 | 'to' => 'icons/yes.xpm', |
---|
477 | 'relatives' => array( |
---|
478 | RELATIVE_CURRENT, |
---|
479 | RELATIVE_USER |
---|
480 | ) |
---|
481 | )); |
---|
482 | </verb> |
---|
483 | </p><p> |
---|
484 | You should notice that no relativity array is needed in the other |
---|
485 | calls that refer to files outside the virtual root, but one is needed |
---|
486 | for calls that include files inside the virtual root. Any RELATIVE |
---|
487 | define can be set as the default and works in the same fashion. To |
---|
488 | retrieve the currently set define, use get_relative (). Note that |
---|
489 | the relativity is reset after each page request; that is, it's good |
---|
490 | only for the life of the current page loading, and is not stored |
---|
491 | in session management. |
---|
492 | </p> |
---|
493 | <sect> |
---|
494 | Function reference<label id="sec:function_reference" > |
---|
495 | <p> |
---|
496 | To view the function reference for the VFS, use the doc/inlinedocparser.php |
---|
497 | 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">. |
---|
498 | </p> |
---|
499 | <sect> |
---|
500 | Notes<label id="sec:notes" > |
---|
501 | <sect1> |
---|
502 | Database<label id="sec:database" > |
---|
503 | <p> |
---|
504 | Data about the files and directories within the virtual root |
---|
505 | is kept in the SQL database. Currently, this information includes: |
---|
506 | </p> |
---|
507 | <p> |
---|
508 | <itemize> |
---|
509 | <item> |
---|
510 | File ID (used internally, primary key for table) |
---|
511 | <item> |
---|
512 | Owner ID (phpGW account_id) |
---|
513 | <item> |
---|
514 | Created by ID (phpGW account_id) |
---|
515 | <item> |
---|
516 | Modified by ID (phpGW account_id) |
---|
517 | <item> |
---|
518 | Created (date) |
---|
519 | <item> |
---|
520 | Modified (date) |
---|
521 | <item> |
---|
522 | Size (bytes) |
---|
523 | <item> |
---|
524 | MIME type |
---|
525 | <item> |
---|
526 | Deleteable (Y/N/Other?) |
---|
527 | <item> |
---|
528 | Comment |
---|
529 | <item> |
---|
530 | App (appname of application that created the file) |
---|
531 | <item> |
---|
532 | Directory (directory the file or directory is in) |
---|
533 | <item> |
---|
534 | Name (name of file or directory) |
---|
535 | <item> |
---|
536 | Link directory (if the file or directory is linked, what the |
---|
537 | actual directory is) |
---|
538 | <item> |
---|
539 | Link name (if the file or directory is linked, what the actual |
---|
540 | name is) |
---|
541 | <item> |
---|
542 | Version (numeric version of the file) |
---|
543 | </itemize> |
---|
544 | </p><p> |
---|
545 | The internal names of these (the database column names) are stored |
---|
546 | in the $GLOBALS['phpgw']->vfs->attributes |
---|
547 | array, which is useful for loops, and is guaranteed to be up-to-date. |
---|
548 | </p> |
---|
549 | <p> |
---|
550 | Note that no information is kept about files outside the virtual |
---|
551 | root. If a file is moved outside, all records of it are deleted from |
---|
552 | the database (other than the journaling records). If a file is moved |
---|
553 | into the virtual root, some information, specifically MIME-type, |
---|
554 | is not always stored in the database. The vital information has defaults: |
---|
555 | owner is based on where the file is being stored; size is correctly |
---|
556 | read; deleteable is set to Y. |
---|
557 | </p> |
---|
558 | <sect1> |
---|
559 | ACL support<label id="sec:acl_support" > |
---|
560 | <p> |
---|
561 | ACL support is built into the VFS. vfs->acl_check () does |
---|
562 | the actual checking, and is called from all VFS functions as needed. |
---|
563 | If the file or directory sent to acl_check () doesn't exist, the |
---|
564 | permissions for the parent directory are used to determine access. |
---|
565 | ACL checking can be overridden at any time by setting vfs->override_acl. |
---|
566 | For example: |
---|
567 | </p> |
---|
568 | <p> |
---|
569 | <verb> |
---|
570 | $GLOBALS['phpgw']->vfs->override_acl = 1; |
---|
571 | $GLOBALS['phpgw']->vfs->mkdir (array( |
---|
572 | 'string' => $GLOBALS['fakebase']. '/' . $group_array['account_name'], |
---|
573 | 'relatives' => array( |
---|
574 | RELATIVE_NONE |
---|
575 | ) |
---|
576 | )); |
---|
577 | $GLOBALS['phpgw']->vfs->override_acl = 0; |
---|
578 | </verb> |
---|
579 | </p><sect1> |
---|
580 | Function aliases<label id="sec:function_aliases" > |
---|
581 | <p> |
---|
582 | You might have noticed there are some functions that just pass |
---|
583 | the arguments on to other functions. These are provided in part because |
---|
584 | of legacy and in part for convenience. You can use either. Here is |
---|
585 | the list (alias -> actual): |
---|
586 | </p> |
---|
587 | <p> |
---|
588 | <itemize> |
---|
589 | <item> |
---|
590 | copy -> cp |
---|
591 | <item> |
---|
592 | move -> rm |
---|
593 | <item> |
---|
594 | delete -> rm |
---|
595 | <item> |
---|
596 | dir -> ls |
---|
597 | </itemize> |
---|
598 | </p><sect1> |
---|
599 | Fakebase directory (changing /home)<label id="sec:fakebase" > |
---|
600 | <p> |
---|
601 | The old VFS was hard-coded to use '/home' as the fake base directory, |
---|
602 | even though the user never saw it. With the new system, crafty administrators |
---|
603 | may wish to change '/home' to something else, say '/users' or '/public_html'. |
---|
604 | The fake base directory name is stored in $GLOBALS['phpgw']->vfs->fakebase, |
---|
605 | and changing it will transparently change it throughout the VFS and |
---|
606 | all applications. However, this must be done <em>before</em> any data is in |
---|
607 | the VFS database. If you wish to change it afterwords, you'll have |
---|
608 | to manually update the database, replacing the old value with the |
---|
609 | new value. <em>Application programmers need to recognize that /home is |
---|
610 | not absolute, and use $GLOBALS['phpgw']->vfs->fakebase |
---|
611 | instead</em>. I suggest setting $fakebase = $GLOBALS['phpgw']->vfs->fakebase; |
---|
612 | right off the bat to keep things neater. |
---|
613 | </p> |
---|
614 | <sect> |
---|
615 | About this Document |
---|
616 | <sect1> |
---|
617 | Copyright and License |
---|
618 | <p> |
---|
619 | Copyright (c) 2001, 2002 Jason Wies |
---|
620 | </p> |
---|
621 | <p> |
---|
622 | Permission is granted to copy, distribute and/or modify this |
---|
623 | document under the terms of the GNU Free Documentation License, Version |
---|
624 | 1.1 or any later version published by the Free Software Foundation; |
---|
625 | with no Invarient Sections, with no Front-Cover Texts, and no Back-Cover |
---|
626 | Texts. |
---|
627 | </p> |
---|
628 | <p> |
---|
629 | 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">. |
---|
630 | </p> |
---|
631 | <sect1> |
---|
632 | History |
---|
633 | <p> |
---|
634 | Original document released in June 2001 by Jason Wies. |
---|
635 | </p> |
---|
636 | <p> |
---|
637 | Updated February 2002 to include arrayized parameters, single |
---|
638 | quotes, and GLOBALS. |
---|
639 | </p> |
---|
640 | <sect1> |
---|
641 | Contributing |
---|
642 | <p> |
---|
643 | Contributions are always welcome. Please send to the current |
---|
644 | maintainer, Jason Wies, |
---|
645 | </p> |
---|
646 | |
---|
647 | |
---|
648 | </article> |
---|