- sqlfs can store now symlinks (implements symlink and readlink)
- vfs resolves symlinks before calling a mounted stream-wrapper
--> symlinks can be between different mount-points
- filemanger can create symlinks and follows them
- etemplate vfs_widget displays symlinks (to be improved)
Happy testing :-)
sqlfs stores files with fs_id < 100 directly under /sqlfs in the files
dir. They conflict with directories created for fs_id >= 1000.
--> fs_id < 100 are now in a directory /sqlfs/00
You need to run the 1.5.016 update or you will not find the content of
files with fs_id < 100 anymore!
+ path with clickable components
+ human readable size, mode, ...
+ mime icon with integrated thumbnail creation
- link widget uses now vfs-mime for it's icons
- thumbnail creation is now switched on with size 32px by default, it can
be switched of by the admin or user, in doing so explicitly
- mime-icons are moved from filemanager to etemplate, as not everyone
installs filemanager
- filemanager has now 3 display modi:
+ Current directory (with subdirs always on top)
+ Subdirs sorted in
+ Files from subdirs (shows recursive all files and you
can click on the path components thanks to new vfs widget)
a hashed directory structure based on the fs_id and not longer on the
path (which can not be recovered, once the filesystem get's corrupt)
--> Make backups (db AND files directory), before attempting the update !!!!!!!!
- the used storage (default filesystem) can be switched via a get-parameter in the url mounted (eg. sqlfs://default/?storage=db)
- please note the current (php5.2.6) problems:
a) retriving files via streams does NOT work for PDO_mysql (bindColum(,,PDO::PARAM_LOB) does NOT work, string returned)
(there's a workaround implemented, but it requires to allocate memory for the whole file!)
b) uploading/writing files > 1M fail on PDOStatement::execute() (setting PDO::MYSQL_ATTR_MAX_BUFFER_SIZE does NOT help)
(not sure if that's a bug in PDO/PDO_mysql or an accepted limitation)
--> now we need to implement an easy switch in setup to allow admins to use the db backend (does NOT require an directory outside the docroot)
currently you need to use filemanager/cli.php mount"
noticed while working on it:
- memory size error, when renaming a file after posting the list (eg.
clicking on home icon)
- renaming (moving) one file on an existing filename, put the file in an
inaccessible state
- renaming more then once, did not work
--> ToDo: add some ajax to notify the user, when he tries to overwrite
an other file while renaming one
- if you already run the 1.5.003 update (AND modified anything in the VFS), you have to re-run it, to not loose your modifications or risk an inconsistent VFS (DB does not match filesystem)
- to re-run the 1.5.003 update (only if your version is already 1.5.003 or bigger!) run the following sql:
UPDATE egw_applications SET app_version=1.5.002 WHERE app_name=phpgwapi
- the new vfs supports now an extended ACL, if that is supported by the backend (sqlfs only currently)
- eacl allows to set separate recursive acl rights for different users or groups on a directory (and subdirs)
- former group grants of group dirs are converted to eacl, thought we only support read or read+write access (no extra add or delete)
- attachments via the links class now also use a stream wrapper interface (links_stream_wrapper) and WebDAV as download handler (which requires no longer filemanager run rights)
- read rights are not checks in each traversed directory (via sql in a single query to locate the path)
- diropen additionally checks for execute rights
- fopen checks for read or write depending on the mode
- chmod, chgrp, chown methods in sqlfs and egw_vfs/vfs plus an egw_vfs::$is_root var used to grant root rights (no access controll and chown or chgrp without being the owner of a file)
- find method (some more params to come) to recursivly search and optionaly execute some callback
- egw_vfs::remove doing a "rm -r" / recursive remove or dirs and files
- new files or dirs inherit the perms and ownership from the parent directory (no umask)
- files/dirs the user has no read rights, in a directory where he has no write rights, get hidden (eg. not showing all the other users / groups home dirs
- many new cli commands (chmod, chgrp, chown, find), recursive option for most commands and the ability to use it with root rights, see the usage message if called without options
- "cp -r -p" to copy a whole tree incl. ownership and perms, eg. backing up /home to /backup
