I just tried the patch adding symlinks to the vfat fs. It was submitted
back at the end of last year but it does not seem to have made it into the
kernel sources. I was unable to find a discussion on this. Symlink support
in vfat is really useful when you are sharing a vfat volume on a dual
booted system. I tried patching a 2.5.X kernel but the page cache changes
mean that the patch needs reworking.
Do you have any updates to the patch Jan?
Here is the readme and the patch again:
------- readme -------------------------------------------------
Symlink support for VFAT filesystem for Linux 2.4
Jan Pazdziora, [email protected]
October 31, 2001.
In Windows, there are so called shortcuts that provide ways of
referencing other files. We will use these to support symlinks on VFAT
partitions under Linux. This patch adds the support to fat/vfat
filesystem source.
Shortcuts are normal files with extension .lnk. That means that from
now on, no regular file on VFAT with symlinks support will be allowed
to have this extension.
The .lnk files not only point to other files but can also hold
information about ways of starting the referenced file, with which
program and parameters. Something like .pif was. The format is
rather complex, and is described by Jesse Hager at
http://www.wotsit.org/download.asp?f=shortcut.
There are three plus one fields of interest here:
1) Relative path -- if it is present we will use it to mean relative
symlink, and when writing relative symlink, we will fill this
field.
2) Network location, in a form \\hostname\path. We won't try to
resolve it, except one special case, \\localhost\path, which will
mean /path, absolute symlink.
3) Local location, in a form C:\path. We won't try to resolve this and
we will never write this kind of link, because we don't know what
the driver letters are.
4) Description field -- Cygwin seems to use it to store the absolute
symlinks, we will write it to contain the symlink path (relative or
absolute).
This patch makes symlink resolving the default. You can mount the
filesystem with an option -o nosymlinks, that will switch the symlink
support off and you will see the base .lnk files.
This patch was tested on Linux kernel 2.4.13 and on Windows ME.
Questions, requests for comment:
If we had the information about drive letter available, we would be
able to resolve the C:\Windows links correctly as well. Note that
inside one drive (shortcut from D: to some other location on D:), the
relative path seems to always be present, so it only starts to be
needed and interesting with links that go accross the Windows drive
boundary. Perhaps some /etc/windrives.conf file? Or a /proc support?
Suggestions welcome.
Cygwin doesn't seem to support the network and local symlinks under
Windows well. It is unhappy with the Network/local part. I believe
that it is a problem of Cygwin (do they do their own symlink
resolution?) and I might be able to get a patch to make Cygwin work
properly as well.
The patch adds minor tweaks into some common code, and also some
bigger functions for symlink creating and resolving. These could be
moved into separate file, from vfat/namei.c and fat/file.c. But due to
a way the fat/vfat/msdos filesystem sypport is structured, the support
(at least partial) will probably always need to be in the common fat
base.
Comments welcome.
diff -ru linux-2.4.13-orig/fs/fat/dir.c linux-2.4.13/fs/fat/dir.c
--- linux-2.4.13-orig/fs/fat/dir.c Fri Oct 12 22:48:42 2001
+++ linux-2.4.13/fs/fat/dir.c Mon Oct 29 22:05:43 2001
@@ -179,6 +179,13 @@
return len;
}
+static int is_symlink(char *extension)
+{
+ if (strncmp(extension, "LNK", 3) == 0)
+ return 1;
+ return 0;
+}
+
/*
* Return values: negative -> error, 0 -> not found, positive -> found,
* value is the total amount of slots, including the shortname entry.
@@ -197,6 +204,7 @@
char work[8], bufname[260]; /* 256 + 4 */
int uni_xlate = MSDOS_SB(sb)->options.unicode_xlate;
int utf8 = MSDOS_SB(sb)->options.utf8;
+ int showsymlinks = MSDOS_SB(sb)->options.symlinks;
unsigned short opt_shortname = MSDOS_SB(sb)->options.shortname;
int ino, chl, i, j, last_u, res = 0;
loff_t cpos = 0;
@@ -319,6 +327,9 @@
xlate_len = utf8
?utf8_wcstombs(bufname, bufuname, sizeof(bufname))
:uni16_to_x8(bufname, bufuname, uni_xlate, nls_io);
+ if (showsymlinks && (xlate_len == name_len + 4)
+ && is_symlink(de->ext))
+ xlate_len -= 4;
if (xlate_len == name_len)
if ((!anycase && !memcmp(name, bufname, xlate_len)) ||
(anycase && !fat_strnicmp(nls_io, name, bufname,
@@ -329,6 +340,9 @@
xlate_len = utf8
?utf8_wcstombs(bufname, unicode, sizeof(bufname))
:uni16_to_x8(bufname, unicode, uni_xlate, nls_io);
+ if (showsymlinks && (xlate_len == name_len + 4)
+ && is_symlink(de->ext))
+ xlate_len -= 4;
if (xlate_len != name_len)
continue;
if ((!anycase && !memcmp(name, bufname, xlate_len)) ||
@@ -367,6 +381,7 @@
int isvfat = MSDOS_SB(sb)->options.isvfat;
int utf8 = MSDOS_SB(sb)->options.utf8;
int nocase = MSDOS_SB(sb)->options.nocase;
+ int showsymlinks = MSDOS_SB(sb)->options.symlinks;
unsigned short opt_shortname = MSDOS_SB(sb)->options.shortname;
int ino, inum, chi, chl, i, i2, j, last, last_u, dotoffset = 0;
loff_t cpos;
@@ -556,6 +571,8 @@
}
if (!long_slots||shortnames) {
+ if (showsymlinks && i > 4 && is_symlink(de->ext))
+ i -= 4;
if (both)
bufname[i] = '\0';
if (filldir(dirent, bufname, i, *furrfu, inum,
@@ -567,6 +584,8 @@
? utf8_wcstombs(longname, unicode, sizeof(longname))
: uni16_to_x8(longname, unicode, uni_xlate,
nls_io);
+ if (showsymlinks && long_len > 4 && is_symlink(de->ext))
+ long_len -= 4;
if (both) {
memcpy(&longname[long_len+1], bufname, i);
long_len += i;
diff -ru linux-2.4.13-orig/fs/fat/file.c linux-2.4.13/fs/fat/file.c
--- linux-2.4.13-orig/fs/fat/file.c Sun Aug 12 19:56:56 2001
+++ linux-2.4.13/fs/fat/file.c Wed Oct 31 16:06:48 2001
@@ -16,6 +16,7 @@
#include <linux/string.h>
#include <linux/pagemap.h>
#include <linux/fat_cvf.h>
+#include <linux/slab.h>
#include <asm/uaccess.h>
#include <asm/system.h>
@@ -36,6 +37,15 @@
setattr: fat_notify_change,
};
+int fat_readlink(struct dentry *dentry, char *buffer, int buflen);
+int fat_follow_link(struct dentry *dentry, struct nameidata *nd);
+
+struct inode_operations fat_symlink_inode_operations = {
+ readlink: fat_readlink,
+ follow_link: fat_follow_link,
+ setattr: fat_notify_change,
+};
+
ssize_t fat_file_read(
struct file *filp,
char *buf,
@@ -134,3 +144,201 @@
inode->i_ctime = inode->i_mtime = CURRENT_TIME;
mark_inode_dirty(inode);
}
+
+#define FAT_SYMLINK_SHELL_ITEM_LIST 0x01
+#define FAT_SYMLINK_FILE_LOCATION 0x02
+#define FAT_SYMLINK_RELATIVE 0x08
+#define FAT_SYMLINK_LOCAL 0x01
+#define FAT_SYMLINK_NETWORK 0x02
+#define FAT_SYMLINK_ABSOLUTE "\\\\localhost\\"
+
+int fat_getlink(struct dentry *dentry, char *buffer, int buflen,
+ char **outbuffer)
+{
+ struct page * page;
+ struct address_space *mapping = dentry->d_inode->i_mapping;
+ char * ptr;
+ int ret = -EIO;
+ int offset = 76;
+ unsigned char flags;
+ *outbuffer = buffer;
+
+ page = read_cache_page(mapping, 0, (filler_t *)mapping->a_ops->readpage,
+ NULL);
+ if (IS_ERR(page))
+ goto sync_fail;
+ wait_on_page(page);
+ if (!Page_Uptodate(page))
+ goto async_fail;
+ ptr = kmap(page);
+
+ if (!(ptr && *ptr == 'L')) /* FIXME: test cele signatury */
+ goto fail_and_free_page;
+
+ flags = *(ptr + 20);
+
+ if (flags & FAT_SYMLINK_RELATIVE) {
+ int i, len;
+ for (i = 0; i <= 2; i++) {
+ if (flags & (1 << i)) {
+ offset += CF_LE_W(*(__u16 *)(ptr + offset));
+ if (i == 0 || i == 2)
+ offset += 2;
+ }
+ }
+ len = CF_LE_W(*(__u16 *)(ptr + offset));
+ if (!buffer) {
+ *outbuffer = kmalloc(len + 1, GFP_KERNEL);
+ if (!(*outbuffer)) {
+ ret = -ENOMEM;
+ goto fail_and_free_page;
+ }
+ memcpy(*outbuffer, ptr + offset + 2, len);
+ } else {
+ if (len > buflen) {
+ len = buflen;
+ }
+ if (copy_to_user(buffer, ptr + offset + 2, len + 1)) {
+ ret = -EFAULT;
+ goto fail_and_free_page;
+ }
+ }
+ (*outbuffer)[len] = 0;
+ for (i = 0; i < len; i++) {
+ if ((*outbuffer)[i] == '\\')
+ (*outbuffer)[i] = '/';
+ }
+ ret = len;
+ } else if (flags & FAT_SYMLINK_FILE_LOCATION) {
+ unsigned char loc_flags;
+ char * first_part = NULL;
+ char * final_part = NULL;
+ int first_part_len, final_part_len;
+ int insert_slash = 0;
+ int total_len;
+
+ if (flags & FAT_SYMLINK_SHELL_ITEM_LIST) {
+ offset += CF_LE_W(*(__u16 *)(ptr + offset)) + 2;
+ }
+ loc_flags = *(ptr + offset + 8);
+
+ if (loc_flags & FAT_SYMLINK_NETWORK) {
+ int new_offset = offset
+ + CF_LE_W(*(__u16 *)(ptr + offset + 20));
+ new_offset += CF_LE_W(*(__u16 *)(ptr + new_offset + 8));
+ first_part = ptr + new_offset;
+ } else if (loc_flags & FAT_SYMLINK_LOCAL) {
+ first_part = ptr + offset
+ + CF_LE_W(*(__u16 *)(ptr + offset + 16));
+ }
+
+ if (!first_part)
+ goto fail_and_free_page;
+
+ first_part_len = strlen(first_part);
+ if (!strnicmp(first_part, FAT_SYMLINK_ABSOLUTE,
+ strlen(FAT_SYMLINK_ABSOLUTE))) {
+ first_part += strlen(FAT_SYMLINK_ABSOLUTE) - 1;
+ first_part_len += 1 - strlen(FAT_SYMLINK_ABSOLUTE);
+ }
+
+ final_part = ptr + offset
+ + CF_LE_W(*(__u16 *)(ptr + offset + 24));
+ final_part_len = strlen(final_part);
+
+ if (final_part_len && (first_part[first_part_len - 1] != '\\'))
+ insert_slash = 1;
+
+ ret = total_len = first_part_len + insert_slash
+ + final_part_len;
+ if (!buffer) {
+ int i;
+ *outbuffer = kmalloc(first_part_len + insert_slash
+ + final_part_len + 1, GFP_KERNEL);
+ if (!(*outbuffer)) {
+ ret = -ENOMEM;
+ goto fail_and_free_page;
+ }
+
+ for (i = 0; i < first_part_len; i++) {
+ if (first_part[i] == '\\')
+ (*outbuffer)[i] = '/';
+ else
+ (*outbuffer)[i] = first_part[i];
+ }
+ if (insert_slash) {
+ (*outbuffer)[i] = '/';
+ i++;
+ }
+ for (i = 0; i < final_part_len; i++) {
+ if (final_part[i] == '\\')
+ (*outbuffer)[first_part_len
+ + insert_slash + i] = '/';
+ else
+ (*outbuffer)[first_part_len
+ + insert_slash + i] = final_part[i];
+ }
+ (*outbuffer)[first_part_len + insert_slash + i] = 0;
+ } else {
+ int i;
+ if (total_len > buflen)
+ total_len = buflen;
+ if (copy_to_user(buffer, first_part,
+ min(first_part_len, buflen))) {
+ ret = -EFAULT;
+ goto fail_and_free_page;
+ }
+ if (first_part_len + 1 < buflen) {
+ if (insert_slash
+ && copy_to_user(buffer
+ + first_part_len, "/", 1)) {
+ ret = -EFAULT;
+ goto fail_and_free_page;
+ }
+ if (copy_to_user(buffer + first_part_len
+ + insert_slash, final_part,
+ min(final_part_len, buflen
+ - first_part_len
+ - insert_slash))) {
+ ret = -EFAULT;
+ goto fail_and_free_page;
+ }
+ }
+ for (i = 0; i < min(buflen, first_part_len
+ + insert_slash + final_part_len); i++) {
+ if (buffer[i] == '\\')
+ buffer[i] = '/';
+ }
+ buffer[total_len] = '\000';
+ }
+ }
+
+fail_and_free_page:
+ kunmap(page);
+async_fail:
+ page_cache_release(page);
+sync_fail:
+ return ret;
+}
+
+int fat_readlink(struct dentry *dentry, char *buffer, int buflen)
+{
+ char * out;
+ if (dentry->d_inode->i_size > PAGE_SIZE)
+ return -ENAMETOOLONG;
+ return fat_getlink(dentry, buffer, buflen, &out);
+}
+
+int fat_follow_link(struct dentry *dentry, struct nameidata *nd)
+{
+ int res;
+ char * buffer;
+ if (dentry->d_inode->i_size > PAGE_SIZE)
+ return -ENAMETOOLONG;
+ fat_getlink(dentry, NULL, 0, &buffer);
+ res = vfs_follow_link(nd, buffer);
+ if (buffer)
+ kfree(buffer);
+ return res;
+}
+
diff -ru linux-2.4.13-orig/fs/fat/inode.c linux-2.4.13/fs/fat/inode.c
--- linux-2.4.13-orig/fs/fat/inode.c Fri Oct 12 22:48:42 2001
+++ linux-2.4.13/fs/fat/inode.c Mon Oct 29 22:18:42 2001
@@ -223,6 +223,7 @@
opts->nocase = 0;
opts->shortname = 0;
opts->utf8 = 0;
+ opts->symlinks = 0;
opts->iocharset = NULL;
*debug = *fat = 0;
@@ -852,6 +853,13 @@
return 0;
}
+static int is_symlink(char *extension)
+{
+ if (strncmp(extension, "LNK", 3) == 0)
+ return 1;
+ return 0;
+}
+
static int fat_writepage(struct page *page)
{
return block_write_full_page(page,fat_get_block);
@@ -940,6 +948,12 @@
inode->i_size = CF_LE_L(de->size);
inode->i_op = &fat_file_inode_operations;
inode->i_fop = &fat_file_operations;
+ if (MSDOS_SB(sb)->options.symlinks && is_symlink(de->ext)) {
+ inode->i_mode &= ~ S_IFREG;
+ inode->i_mode |= S_IFLNK;
+ inode->i_op = &fat_symlink_inode_operations;
+ inode->i_fop = NULL;
+ }
inode->i_mapping->a_ops = &fat_aops;
MSDOS_I(inode)->mmu_private = inode->i_size;
}
diff -ru linux-2.4.13-orig/fs/vfat/namei.c linux-2.4.13/fs/vfat/namei.c
--- linux-2.4.13-orig/fs/vfat/namei.c Fri Oct 12 22:48:42 2001
+++ linux-2.4.13/fs/vfat/namei.c Thu Nov 1 09:14:43 2001
@@ -109,6 +109,7 @@
opts->numtail = 1;
opts->utf8 = 0;
opts->shortname = VFAT_SFN_DISPLAY_LOWER | VFAT_SFN_CREATE_WIN95;
+ opts->symlinks = 1;
/* for backward compatible */
if (opts->nocase) {
opts->nocase = 0;
@@ -155,6 +156,8 @@
| VFAT_SFN_CREATE_WIN95;
else
ret = 0;
+ } else if (!strcmp(this_char,"nosymlinks")) {
+ opts->symlinks = 0;
}
if (this_char != options)
*(this_char-1) = ',';
@@ -213,7 +216,9 @@
name = qstr->name;
while (len && name[len-1] == '.')
len--;
-
+ if (MSDOS_SB(dentry->d_inode->i_sb)->options.symlinks
+ && len > 4 && strnicmp(name + len - 4, ".lnk", 4) == 0)
+ len -= 4;
qstr->hash = full_name_hash(name, len);
return 0;
@@ -236,6 +241,9 @@
name = qstr->name;
while (len && name[len-1] == '.')
len--;
+ if (MSDOS_SB(dentry->d_inode->i_sb)->options.symlinks
+ && len > 4 && strnicmp(name + len - 4, ".lnk", 4) == 0)
+ len -= 4;
hash = init_name_hash();
while (len--)
@@ -1248,6 +1256,8 @@
}
+static int vfat_symlink ( struct inode *dir, struct dentry *dentry,
+ const char *symname);
/* Public inode operations for the VFAT fs */
struct inode_operations vfat_dir_inode_operations = {
@@ -1258,6 +1268,7 @@
rmdir: vfat_rmdir,
rename: vfat_rename,
setattr: fat_notify_change,
+ symlink: vfat_symlink,
};
struct super_block *vfat_read_super(struct super_block *sb,void *data,
@@ -1285,3 +1296,139 @@
return res;
}
+
+/*
+ * Function vfat_symlink_fill takes a pointer to target of the
+ * new symlink and a pointer to buffer and creates correct content
+ * of the buffer, to be written as a file specifying the symlink.
+ * If however the buffer pointer is NULL, it doesn't write to it.
+ * In any case it returns the length of the new file, so this function
+ * should be called twice -- first with NULL as buffer and after
+ * allocating the exact memory, with the pointer to that buffer.
+ *
+ * The relative symlink is stored as relative symlink with the description
+ * the same as the symlink, the absolute symlink is stored as \\localhost\
+ * network symlink with description matching the symlink path.
+ */
+
+#define FAT_SYMLINK_FILE_START "L\000\000\000\001\024\002\000\000\000\000\000\xc0\000\000\000\000\000\000\x46"
+#define FAT_SYMLINK_LOCALHOST "\\\\localhost\\"
+
+static int vfat_symlink_fill(const char * symname, char * buffer)
+{
+ int res = 0;
+ int symnamelen = strlen(symname);
+
+ if (buffer) {
+ memcpy(buffer, FAT_SYMLINK_FILE_START, 20);
+ memset(buffer + 20, 0, 76 - 20);
+ *(__u32*)(buffer + 60) = CT_LE_L(1);
+ }
+
+ if (*symname == '/') {
+ res = 76 + symnamelen + 12 + 1 + 20 + 28 + 1 + symnamelen + 2;
+ if (buffer) {
+ int i;
+ *(__u32*)(buffer + 20) = CT_LE_L(6);
+ *(__u32*)(buffer + 76) = CT_LE_L(res - 76);
+ *(__u32*)(buffer + 80) = CT_LE_L(28);
+ *(__u32*)(buffer + 84) = CT_LE_L(2);
+ *(__u32*)(buffer + 96) = CT_LE_L(28);
+ *(__u32*)(buffer + 100) = CT_LE_L(28 + 20 + 13);
+ *(__u32*)(buffer + 104) = CT_LE_L(symnamelen + 12 + 1 + 20);
+ *(__u32*)(buffer + 112) = CT_LE_L(20);
+ memcpy(buffer + 124, FAT_SYMLINK_LOCALHOST, 13);
+ for (i = 1; i <= symnamelen; i++) {
+ if (*(symname + i) == '/')
+ *(buffer + 124 + 12 + i) = '\\';
+ else
+ *(buffer + 124 + 12 + i)
+ = *(symname + i);
+ }
+ *(__u32*)(buffer + 124 + 12 + symnamelen + 1)
+ = CT_LE_W(symnamelen);
+ memcpy(buffer + 124 + 12 + symnamelen + 1 + 2,
+ symname, symnamelen);
+ }
+ } else {
+ res = 76 + 2 + symnamelen + 2 + symnamelen + 1;
+ if (buffer) {
+ int i;
+ *(__u32*)(buffer + 20) = CT_LE_L(12);
+ *(__u16*)(buffer + 76) = CT_LE_W(symnamelen);
+ memcpy(buffer + 78, symname, symnamelen);
+
+ *(__u16*)(buffer + 78 + symnamelen)
+ = CT_LE_W(symnamelen);
+ for (i = 0; i < symnamelen; i++) {
+ if (*(symname + i) == '/')
+ *(buffer + 80 + symnamelen + i) = '\\';
+ else
+ *(buffer + 80 + symnamelen + i)
+ = *(symname + i);
+ }
+ }
+ }
+
+ return res;
+}
+
+/*
+ * Function vfat_symlink creates new symlink file on a vfat partition.
+ * First it adds the .lnk extension which on vfat will denote the symlink
+ * type. To do this, since we're making the name longer, we may need
+ * to allocate new d_name.name. Then we allocate buffer for the content
+ * of the symlink file, let vfat_symlink_fill to fill the buffer, create
+ * the file, release the buffer and are done.
+ */
+
+static int vfat_symlink ( struct inode *dir, struct dentry *dentry,
+ const char *symname)
+{
+ char * buffer;
+ int ret, len;
+
+ int d_name_len = dentry->d_name.len;
+
+ if (d_name_len + 4 + 1 > sizeof(dentry->d_iname)) {
+ char * new_name = kmalloc(d_name_len + 4 + 1, GFP_KERNEL);
+ if (!new_name) {
+ ret = -ENOMEM;
+ goto out;
+ }
+ memcpy(new_name, dentry->d_name.name, d_name_len);
+ if (dentry->d_name.name != dentry->d_iname)
+ kfree(dentry->d_name.name);
+ dentry->d_name.name = new_name;
+ }
+ memcpy((unsigned char *)dentry->d_name.name + d_name_len, ".lnk", 5);
+ dentry->d_name.len += 4;
+
+ ret = vfat_create(dir, dentry, S_IFLNK | 0777);
+ if (ret) {
+ printk(KERN_WARNING "vfat_symlink: create failed (%d)\n", ret);
+ goto out;
+ }
+
+ buffer = kmalloc(vfat_symlink_fill(symname, NULL), GFP_KERNEL);
+ if (!buffer) {
+ ret = -ENOMEM;
+ goto out_unlink;
+ }
+
+ len = vfat_symlink_fill(symname, buffer);
+ ret = block_symlink(dentry->d_inode, buffer, len);
+ kfree(buffer);
+
+ if (ret < 0)
+ goto out_unlink;
+out:
+ return ret;
+
+out_unlink:
+ printk(KERN_WARNING "vfat_symlink: write failed, unlinking\n");
+ vfat_unlink (dir, dentry);
+ d_drop(dentry);
+ goto out;
+}
+
diff -ru linux-2.4.13-orig/include/linux/msdos_fs.h linux-2.4.13/include/linux/msdos_fs.h
--- linux-2.4.13-orig/include/linux/msdos_fs.h Fri Oct 12 22:48:42 2001
+++ linux-2.4.13/include/linux/msdos_fs.h Tue Oct 30 21:07:07 2001
@@ -56,7 +56,7 @@
#define DELETED_FLAG 0xe5 /* marks file as deleted when in name[0] */
#define IS_FREE(n) (!*(n) || *(const unsigned char *) (n) == DELETED_FLAG)
-#define MSDOS_VALID_MODE (S_IFREG | S_IFDIR | S_IRWXU | S_IRWXG | S_IRWXO)
+#define MSDOS_VALID_MODE (S_IFREG | S_IFDIR | S_IRWXU | S_IRWXG | S_IRWXO | S_IFLNK )
/* valid file mode bits */
#define MSDOS_SB(s) (&((s)->u.msdos_sb))
@@ -271,6 +271,7 @@
/* fat/file.c */
extern struct file_operations fat_file_operations;
extern struct inode_operations fat_file_inode_operations;
+extern struct inode_operations fat_symlink_inode_operations;
extern ssize_t fat_file_read(struct file *filp, char *buf, size_t count,
loff_t *ppos);
extern int fat_get_block(struct inode *inode, long iblock,
@@ -278,6 +279,11 @@
extern ssize_t fat_file_write(struct file *filp, const char *buf, size_t count,
loff_t *ppos);
extern void fat_truncate(struct inode *inode);
+/*
+extern int fat_readlink(struct dentry *dentry, char *buffer, int buflen);
+extern int fat_follow_link(struct dentry *, struct nameidata *);
+*/
+
/* fat/inode.c */
extern void fat_hash_init(void);
diff -ru linux-2.4.13-orig/include/linux/msdos_fs_sb.h linux-2.4.13/include/linux/msdos_fs_sb.h
--- linux-2.4.13-orig/include/linux/msdos_fs_sb.h Fri Oct 12 22:48:42 2001
+++ linux-2.4.13/include/linux/msdos_fs_sb.h Mon Oct 29 22:06:24 2001
@@ -26,7 +26,8 @@
numtail:1, /* Does first alias have a numeric '~1' type tail? */
atari:1, /* Use Atari GEMDOS variation of MS-DOS fs */
fat32:1, /* Is this a FAT32 partition? */
- nocase:1; /* Does this need case conversion? 0=need case conversion*/
+ nocase:1, /* Does this need case conversion? 0=need case conversion*/
+ symlinks:1; /* Do we want to support symlinks? */
};
struct msdos_sb_info {
On Sat, Jun 08, 2002 at 06:53:49PM -0700, [email protected] wrote:
> I just tried the patch adding symlinks to the vfat fs. It was submitted
> back at the end of last year but it does not seem to have made it into the
> kernel sources. I was unable to find a discussion on this. Symlink support
> in vfat is really useful when you are sharing a vfat volume on a dual
> booted system. I tried patching a 2.5.X kernel but the page cache changes
> mean that the patch needs reworking.
>
> Do you have any updates to the patch Jan?
No, I don't. I did not receive any feedback since I sent in the patch
to linux-kernel, so I concluded that people do not consider lack
of shortcut/symlink support a problem. For me it's something that
would be nice to have but I don't feel like pushing it in.
I might be able to upgrade the patch for the 2.5 kernal line, but
I'd like to hear some comments about the code in general.
Yours,
--
------------------------------------------------------------------------
Jan Pazdziora | [email protected] | http://www.fi.muni.cz/~adelton/
... all of these signs saying sorry but we're closed ...
------------------------------------------------------------------------
On Sunday 09 June 2002 18:44, Jan Pazdziora wrote:
> On Sat, Jun 08, 2002 at 06:53:49PM -0700, [email protected] wrote:
> > I just tried the patch adding symlinks to the vfat fs. It was submitted
> > back at the end of last year but it does not seem to have made it into the
> > kernel sources. I was unable to find a discussion on this. Symlink support
> > in vfat is really useful when you are sharing a vfat volume on a dual
> > booted system. I tried patching a 2.5.X kernel but the page cache changes
> > mean that the patch needs reworking.
> >
> > Do you have any updates to the patch Jan?
>
> No, I don't. I did not receive any feedback since I sent in the patch
> to linux-kernel, so I concluded that people do not consider lack
> of shortcut/symlink support a problem. For me it's something that
> would be nice to have but I don't feel like pushing it in.
More often than not, when a post doesn't get any responses it's a good sign:
it means nobody disagrees. It can of course also mean that nobody read it,
but that's not very likely on this list, especially if you put [RFC] in the
subject line.
> I might be able to upgrade the patch for the 2.5 kernal line, but
> I'd like to hear some comments about the code in general.
To increase the chance of getting comments, cc people who might be
interested, particularly subsystem maintainers. For this one, cc'ing fsdevel
would be a good idea too. It's a low volume list, but the traffic on it does
get read by many people with a clue. If you want to be really sure of
getting feedback, cc Linus or Al Viro.
Personally, it sounds like support for shortcuts as symlinks is a natural and
needed improvement, though I haven't looked at the the internal details.
(Shortcuts arrived in Microsoft-land at about the time I lost interest.) I'm
kind of surprised the support isn't already there. Perhaps you could briefy
describe how shortcuts work on vfat?
--
Daniel
On Sun, 2002-06-09 at 10:44, Daniel Phillips wrote:
> Personally, it sounds like support for shortcuts as symlinks is a natural and
> needed improvement, though I haven't looked at the the internal details.
> (Shortcuts arrived in Microsoft-land at about the time I lost interest.) I'm
> kind of surprised the support isn't already there. Perhaps you could briefy
> describe how shortcuts work on vfat?
>
Putting shortcut support into the VFAT driver is as bad a decision as
the automatic text-file CRLF->LF conversions was, for several reasons.
First of all, some programs (WINE) will actually want to use the .lnk
files, and transparently converting them to symlinks will complicate
that.
More importantly, shortcuts are a hell of a lot more complicated than
has been implied. Not only can they point to local files or UNCs (the
\\server\share\path notation), they can also point to any object in the
(Windows) shell's namespace, which includes lots of virtual objects that
don't actually exist on disk. With the release of the Windows Installer
package manager, Microsoft has also added support for shortcuts that
will either invoke the target application or prompt for that
application's installation when they're activiated, leading to much more
complexity to either deal with such a shortcut, or to recognize it and
ignore it.
Finally, I haven't seen any justification for why symlinks on VFAT are
needed, beyond some vague statements that it's useful when dual booting.
Face it, VFAT isn't a Unix filesystem and introducing ugly hacks to make
it more similar to one will only cause problems in the long run. If you
want symlinks, use a real filesystem or use umsdos on your favorite FAT
filesystem. (Assuming that umsdos still works...).
- Nicholas
P.S. As to how shortcuts actually work, they're just ordinary files on
disk in some undocumented, proprietary, and frequently changing format
that the Windows Shell knows how to interpret.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On June 9, 2002 13:05, Daniel Phillips wrote:
> On Sunday 09 June 2002 20:58, Ryan Cumming wrote:
> > Shortcuts are very similar to .desktop files in KDE or Gnome. They
> > contain the location of their destination file, and possibly other
> > information, such as an icon. Win32 shortcuts are implemented at a higher
> > level than symbolic links in Unix; it's fairly easy to trick Notepad in
> > to editing shortcuts as text files.
> >
> > I would suggest that turning shortcuts in to symlinks should be disabled
> > by default. WINE actually cares about some of the shortcut information
> > beyond the destination file; turning the shortcut in to a symlink would
> > destroy that information.
>
> Thanks for that. Yes, it seems shortcuts are not very much like symlinks.
> The question is: does the filesystem itself interpret them, or does the
> Windows shell? If the latter, yes, I'd agree that it makes sense to handle
> them in Wine, not the filesystem. The behaviour of MSDos running under
> Windows (I think ME was the last version that had one of those) can be used
> as an arbiter: if MSDos handles the shortcut, then it's a symlink and
> should be handled as such (that particular form of shortcut anyway). If
> MSDos doesn't handle it then it's clear that linux vfat shouldn't either.
DOS won't interpret shortcuts. Shortcuts are almost entirely implemented in
the Windows shell.
- -Ryan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE9A7lmLGMzRzbJfbQRAirqAJ4hawIEMoe7SWEn+k8BB1WjH1KLOQCeLFlP
DhI7oOuauSn+YUbgwE/vAPY=
=f4tR
-----END PGP SIGNATURE-----
On 09 Jun 2002 11:53:32 -0700
Nicholas Miell <[email protected]> escribi?:
> First of all, some programs (WINE) will actually want to use the .lnk
> files, and transparently converting them to symlinks will complicate
> that.
I agree. M$ did .lnk _files_, but really, there's not symlinks in vfat
world. Even msdos doesn't recognize them. I don't remember if it's the
same in NTFS, W2000 & XP are so good that I can't work with them in 32MB
RAM...
And I must say that symlinks are not needed in most of the windows 9X
systems. They aren't really useful for most of the systems. But if
someone needs it, it'd be include as a .config option.....
Hi,
On Sun, 9 Jun 2002, Diego Calleja wrote:
> I agree. M$ did .lnk _files_, but really, there's not symlinks in vfat
> world. Even msdos doesn't recognize them. I don't remember if it's the
> same in NTFS, W2000 & XP are so good that I can't work with them in 32MB
> RAM...
Some time ago I found a document proposing a different API for Windows
2002 which was supposed to include symlinks into ntfs, so I don't think
it was there.
Regards,
Thunder
--
German attitude becoming | Thunder from the hill at ngforever
rightaway popular: |
"Get outa my way, | free inhabitant not directly
for I got a mobile phone!" | belonging anywhere
Nicholas Miell writes:
> Putting shortcut support into the VFAT driver is as bad a decision as
> the automatic text-file CRLF->LF conversions was, for several reasons.
No, NOTHING done with VFAT is as bad as the text conversion.
That one was not implementable in any sane way, unless you
think sequential read-only access (like /proc) is sane.
> First of all, some programs (WINE) will actually want to use the .lnk
> files, and transparently converting them to symlinks will complicate
> that.
WINE needs to be able to handle a symlink on ext2, so it can
damn well convert back. It's OK to give WINE some hack to get at
the content; it's not OK to hack bash to interpret .lnk files.
> More importantly, shortcuts are a hell of a lot more complicated than
> has been implied. Not only can they point to local files or UNCs (the
> \\server\share\path notation), they can also point to any object in the
> (Windows) shell's namespace, which includes lots of virtual objects that
> don't actually exist on disk.
One can live with an occasional broken symlink:
"foo" --> "[UNIMPLEMENTED LINK TYPE]"
> Finally, I haven't seen any justification for why symlinks on VFAT are
> needed, beyond some vague statements that it's useful when dual booting.
> Face it, VFAT isn't a Unix filesystem and introducing ugly hacks to make
> it more similar to one will only cause problems in the long run. If you
> want symlinks, use a real filesystem or use umsdos on your favorite FAT
> filesystem. (Assuming that umsdos still works...).
Umsdos is evil.
1. the /DOS thing, done iff mounted on /
2. the fake "hard links" that any user can mess up
Umsdos did help with Linux acceptance though. Lots of people
installed Linux for the first time as Slackware on umsdos.
It's sad that modern installers no longer have this ability.
It was this, and support for crap hardware, that gave Linux
the edge over BSD in the early days.
Today the situation is a little different. We have devfs,
so we don't need device files on the root filesystem.
vfat gives us long filenames. We have per-process namespaces
that could be used to assign a separate /tmp to each user,
thus keeping files separated by UID. It would be pretty
reasonable to create an almost-normal Linux system on vfat.
Copy the setuid stuff to ramfs at boot, use "mount --bind"
and the namespaces to write-protect stuff a user shouldn't
be able to touch, etc. It all works out great. Best of all,
the FAT32 data structures can support the phase-tree
algorithm for perfect data integrity.
System start up is like this:
mount -t vfat /dev/hda1 / # done by kernel
mount -t devfs none /dev # done by kernel
mount -t ramfs none /linux/setuid
tar zxf linux/setuid.tgz
mount --bind /linux/setuid/su /bin/su
mount --bind /linux/setuid/passwd /usr/bin/passwd
mount --bind /linux/setuid/chfn /usr/bin/chfn
...
Then for a login, create a new namespace.
Remount _everything_ read-only to protect it.
(or implement a per-mount uid/gid feature)
Overmount stuff that a normal user shouldn't
even be able to read, or abuse a DOS attribute
bit for this purpose. Mount a per-user /tmp and
home directory. Deliver mail to home directories.
Don't bother commenting on the above unless
you know about the per-process namespaces.
They are critical to doing multi-user on vfat.
The only thing left is to make sure every app
can handle failure to create a hard link.
On Sun, 2002-06-09 at 13:40, Thunder from the hill wrote:
> Hi,
>
> On Sun, 9 Jun 2002, Diego Calleja wrote:
> > I agree. M$ did .lnk _files_, but really, there's not symlinks in vfat
> > world. Even msdos doesn't recognize them. I don't remember if it's the
> > same in NTFS, W2000 & XP are so good that I can't work with them in 32MB
> > RAM...
>
> Some time ago I found a document proposing a different API for Windows
> 2002 which was supposed to include symlinks into ntfs, so I don't think
> it was there.
>
NTFS is a real filesystem, unlike VFAT. It has native support for hard
links, and, IIRC, the version that ships with Windows XP can do
something similar to symbolic links.
On Sun, 2002-06-09 at 13:53, Albert D. Cahalan wrote:
> Nicholas Miell writes:
>
> > Putting shortcut support into the VFAT driver is as bad a decision as
> > the automatic text-file CRLF->LF conversions was, for several reasons.
>
> No, NOTHING done with VFAT is as bad as the text conversion.
> That one was not implementable in any sane way, unless you
> think sequential read-only access (like /proc) is sane.
>
> > First of all, some programs (WINE) will actually want to use the .lnk
> > files, and transparently converting them to symlinks will complicate
> > that.
>
> WINE needs to be able to handle a symlink on ext2, so it can
> damn well convert back. It's OK to give WINE some hack to get at
> the content; it's not OK to hack bash to interpret .lnk files.
Why would bash even want to interpret shortcut files? They're a proprietary,
Windows-only format that have no real use beyond icons in the Start Menu
or on the desktop. Hacking the filesystem to treat something that
fundamentally is not a symlink as a symlink is even stupider than
hacking bash to do the same thing.
> > More importantly, shortcuts are a hell of a lot more complicated than
> > has been implied. Not only can they point to local files or UNCs (the
> > \\server\share\path notation), they can also point to any object in the
> > (Windows) shell's namespace, which includes lots of virtual objects that
> > don't actually exist on disk.
>
> One can live with an occasional broken symlink:
> "foo" --> "[UNIMPLEMENTED LINK TYPE]"
One can also live with "foo.lnk". (It's much easier and saner, too.)
> > Finally, I haven't seen any justification for why symlinks on VFAT are
> > needed, beyond some vague statements that it's useful when dual booting.
> > Face it, VFAT isn't a Unix filesystem and introducing ugly hacks to make
> > it more similar to one will only cause problems in the long run. If you
> > want symlinks, use a real filesystem or use umsdos on your favorite FAT
> > filesystem. (Assuming that umsdos still works...).
>
> [ insane abuse of VFAT for multi-user systems ]
You're not serious, right?
- Nicholas
On 9 Jun 2002, Nicholas Miell wrote:
> Putting shortcut support into the VFAT driver is as bad a decision as
> the automatic text-file CRLF->LF conversions was, for several reasons.
I think these are two different cases. One is the file semantics the other
is the file format itself. CRLF->LF conversion has always been bad even on
the native windows platforms.
> First of all, some programs (WINE) will actually want to use the .lnk
> files, and transparently converting them to symlinks will complicate
> that.
Only the .lnk files that can be properly interpreted as symlinks are
showing up as symlink as far as I can tell. This is quite ok and very
helpful. .lnk file interpretation can be switched off and on as a boot
option.
> More importantly, shortcuts are a hell of a lot more complicated than
> has been implied. Not only can they point to local files or UNCs (the
> \\server\share\path notation), they can also point to any object in the
> (Windows) shell's namespace, which includes lots of virtual objects that
> don't actually exist on disk. With the release of the Windows Installer
> package manager, Microsoft has also added support for shortcuts that
> will either invoke the target application or prompt for that
> application's installation when they're activiated, leading to much more
> complexity to either deal with such a shortcut, or to recognize it and
> ignore it.
As said before the vfat fs would only display the convertable shortcuts
and not all.
> Finally, I haven't seen any justification for why symlinks on VFAT are
> needed, beyond some vague statements that it's useful when dual booting.
> Face it, VFAT isn't a Unix filesystem and introducing ugly hacks to make
> it more similar to one will only cause problems in the long run. If you
> want symlinks, use a real filesystem or use umsdos on your favorite FAT
> filesystem. (Assuming that umsdos still works...).
I cannot decompress a tarball with symlinks on a vfat volume without that
patch. With that patch I can use the vfat volume like a unix fs. I can
boot XP running Cygwin and build another binary from the same sources.
vfat with the patch can *create* symlinks that are compatible with other
oses.
The patch is a must have ....
Nicholas Miell writes:
> On Sun, 2002-06-09 at 13:53, Albert D. Cahalan wrote:
>> Nicholas Miell writes:
>>> First of all, some programs (WINE) will actually want
>>> to use the .lnk files, and transparently converting
>>> them to symlinks will complicate that.
>>
>> WINE needs to be able to handle a symlink on ext2, so it can
>> damn well convert back. It's OK to give WINE some hack to get at
>> the content; it's not OK to hack bash to interpret .lnk files.
>
> Why would bash even want to interpret shortcut files?
Some of the shortcut files are symlinks. Of course
this is disgusting, since bash shouldn't have to be
aware of the underlying filesystem type. One would
have to add disgusting hacks to many programs,
including: ln tar mc cpio
> They're a proprietary,
> Windows-only format
...like vfat itself. You might as well argue for ripping
that out and using a userspace solution like mtools.
> Hacking the filesystem to treat something that
> fundamentally is not a symlink as a symlink
Symlinks are implemented, poorly, as .lnk files.
I don't care if you wish it weren't so. Microsoft
doesn't care either.
>>> More importantly, shortcuts are a hell of a lot more complicated than
>>> has been implied. Not only can they point to local files or UNCs (the
>>> \\server\share\path notation), they can also point to any object in the
>>> (Windows) shell's namespace, which includes lots of virtual objects that
>>> don't actually exist on disk.
>>
>> One can live with an occasional broken symlink:
>> "foo" --> "[UNIMPLEMENTED LINK TYPE]"
>
> One can also live with "foo.lnk". (It's much easier and saner, too.)
It's also unusable from common UNIX tools.
>>> Finally, I haven't seen any justification for why symlinks on VFAT are
>>> needed, beyond some vague statements that it's useful when dual booting.
>>> Face it, VFAT isn't a Unix filesystem and introducing ugly hacks to make
>>> it more similar to one will only cause problems in the long run. If you
>>> want symlinks, use a real filesystem or use umsdos on your favorite FAT
>>> filesystem. (Assuming that umsdos still works...).
>>
>> [ insane abuse of VFAT for multi-user systems ]
>
> You're not serious, right?
I'm very serious. The ability to install without partitioning
is important for hesitant new users.
Why not? The system might feel "unclean" to you, but it's
great for converting the Windows users. Not many people
are willing to trash their one-and-only partition, full of
data, to experiment with a new OS. Regular users don't
keep backups. Linux is the only UNIX-like OS that could
do a respectable job of running multi-user on vfat.
On 9 Jun 2002, Nicholas Miell wrote:
> Why would bash even want to interpret shortcut files? They're a proprietary,
> Windows-only format that have no real use beyond icons in the Start Menu
> or on the desktop. Hacking the filesystem to treat something that
> fundamentally is not a symlink as a symlink is even stupider than
> hacking bash to do the same thing.
vfat is a proprietary windows-only format. Why are we supporting it?
If we do then lets make it as easy to use as possible including symlinks.
> One can also live with "foo.lnk". (It's much easier and saner, too.)
No one cannot untar a source tarball with symlinks in a vfat fs without
the patch. We cannot live with foo.lnk. Its insane not to carry over the
semantics as much as possible.
> > > Finally, I haven't seen any justification for why symlinks on VFAT are
> > > needed, beyond some vague statements that it's useful when dual booting.
> > > Face it, VFAT isn't a Unix filesystem and introducing ugly hacks to make
> > > it more similar to one will only cause problems in the long run. If you
> > > want symlinks, use a real filesystem or use umsdos on your favorite FAT
> > > filesystem. (Assuming that umsdos still works...).
vfat is the only fs that can be shared between microsoft oses and linux.
umsdos mangles filenames and does other ugly things. umsdos is an example
of what not to do with a fs. umsdos is a hack. vfat+symlinks is the
completion of an implementation.
On Sun, 2002-06-09 at 15:06, [email protected] wrote:
> On 9 Jun 2002, Nicholas Miell wrote:
>
> > Why would bash even want to interpret shortcut files? They're a proprietary,
> > Windows-only format that have no real use beyond icons in the Start Menu
> > or on the desktop. Hacking the filesystem to treat something that
> > fundamentally is not a symlink as a symlink is even stupider than
> > hacking bash to do the same thing.
>
> vfat is a proprietary windows-only format. Why are we supporting it?
It may be proprietary, but it is well documented (by Microsoft, even)
and well understood.
And note that trying to fully support VFAT in Linux has been problematic
in the past, especially w.r.t. NFS exports.
> If we do then lets make it as easy to use as possible including symlinks.
>
> > One can also live with "foo.lnk". (It's much easier and saner, too.)
>
> No one cannot untar a source tarball with symlinks in a vfat fs without
> the patch. We cannot live with foo.lnk. Its insane not to carry over the
> semantics as much as possible.
Beating a square peg into a round hole is also rather crazy.
Note that there's nothing stopping you from unpacking the tarball in
cygwin, with it's own (nicely contained, and not nearly as ugly) symlink
hack.
> > > > Finally, I haven't seen any justification for why symlinks on VFAT are
> > > > needed, beyond some vague statements that it's useful when dual booting.
> > > > Face it, VFAT isn't a Unix filesystem and introducing ugly hacks to make
> > > > it more similar to one will only cause problems in the long run. If you
> > > > want symlinks, use a real filesystem or use umsdos on your favorite FAT
> > > > filesystem. (Assuming that umsdos still works...).
>
> vfat is the only fs that can be shared between microsoft oses and linux.
> umsdos mangles filenames and does other ugly things. umsdos is an example
> of what not to do with a fs. umsdos is a hack. vfat+symlinks is the
> completion of an implementation.
>
Don't forget NTFS, SMBFS, ISO-9660, HPFS (if Windows still supports
it...), and plain old FAT.
There's also third-party support for NFS, HFS, VxFS and others.
Hi,
On 9 Jun 2002, Nicholas Miell wrote:
> Note that there's nothing stopping you from unpacking the tarball in
> cygwin, with it's own (nicely contained, and not nearly as ugly) symlink
> hack.
That's a hack in the cygwin libc, isn't it? It's the lib which opens
another file instead of the original, isn't it?
> Don't forget NTFS,
NTFS isn't known to be well writable. Remember the oopses! (Sorry, NTFS
people, if I do you any wrong)
> SMBFS,
...requires the windows system to be up...
> ISO-9660,
...needs to be burned onto CD first...
> HPFS (if Windows still supports it...),
Not by default, I think.
> and plain old FAT.
...which looses long names, IIRC. That's not a choice of choice...
> There's also third-party support for NFS,
...which again requires the windows to be up and running...
> HFS,
...which also needs to be burned onto cd or stored somewhere else...
> VxFS and others.
...which needs to be put somewhere, too...
I think VFAT is really the only real flexible transport fs for
linux->windows.
Regards,
Thunder
--
German attitude becoming | Thunder from the hill at ngforever
rightaway popular: |
"Get outa my way, | free inhabitant not directly
for I got a mobile phone!" | belonging anywhere
On Sun, 2002-06-09 at 15:49, Thunder from the hill wrote:
> Hi,
>
> On 9 Jun 2002, Nicholas Miell wrote:
> > Note that there's nothing stopping you from unpacking the tarball in
> > cygwin, with it's own (nicely contained, and not nearly as ugly) symlink
> > hack.
>
> That's a hack in the cygwin libc, isn't it? It's the lib which opens
> another file instead of the original, isn't it?
Yeah, and it uses the native IShellLink COM interface to do it, which
guarantees future (Windows) compatibility. Misusing the comment field to
store the path is a bit questionable, though.
Actually, if people are so hell-bent on making symlinks work on VFAT,
I'd suggest that they make a LD_PRELOAD'd shared library that intercepts
the open, lstat, symlink, etc. calls and Does The Right Thing on VFAT
filesystems. Much cleaner than putting it in the kernel or in all the
apps that might be used on a VFAT filesystem.
> I think VFAT is really the only real flexible transport fs for
> linux->windows.
Yeah, I'd agree with that (until NTFS can do writing, anyway). I was
just pointing out that there are lots of filesystems that Windows can
use, not just VFAT.
- Nicholas
On Sun, 2002-06-09 at 15:05, Albert D. Cahalan wrote:
> Nicholas Miell writes:
> >> [ insane abuse of VFAT for multi-user systems ]
> >
> > You're not serious, right?
>
> I'm very serious. The ability to install without partitioning
> is important for hesitant new users.
>
> Why not? The system might feel "unclean" to you, but it's
> great for converting the Windows users. Not many people
> are willing to trash their one-and-only partition, full of
> data, to experiment with a new OS. Regular users don't
> keep backups. Linux is the only UNIX-like OS that could
> do a respectable job of running multi-user on vfat.
The same thing can be (and is) done using initrd+loopback, with a lot
less effort and all of the usual Unix filesystem semantics.
- Nicholas
On 9 Jun 2002, Nicholas Miell wrote:
> Yeah, and it uses the native IShellLink COM interface to do it, which
> guarantees future (Windows) compatibility. Misusing the comment field to
> store the path is a bit questionable, though.
The format is standardized. See the orginal readme by Jan.
> Actually, if people are so hell-bent on making symlinks work on VFAT,
> I'd suggest that they make a LD_PRELOAD'd shared library that intercepts
> the open, lstat, symlink, etc. calls and Does The Right Thing on VFAT
> filesystems. Much cleaner than putting it in the kernel or in all the
> apps that might be used on a VFAT filesystem.
Yuck that could potentially mess up all sorts of other things. Why is it
so difficult to just do it the easy way. .lnk files on linux and other
fses do not make much sense. On vfat it does.
On 9 Jun 2002, Nicholas Miell wrote:
> Note that there's nothing stopping you from unpacking the tarball in
> cygwin, with it's own (nicely contained, and not nearly as ugly) symlink
> hack.
Cygwin symlinks are compatible with the implementation in the patch,,,
Nicholas Miell writes:
> On Sun, 2002-06-09 at 15:05, Albert D. Cahalan wrote:
>> Nicholas Miell writes:
>>>> [ insane abuse of VFAT for multi-user systems ]
>>>
>>> You're not serious, right?
>>
>> I'm very serious. The ability to install without partitioning
>> is important for hesitant new users.
>>
>> Why not? The system might feel "unclean" to you, but it's
>> great for converting the Windows users. Not many people
>> are willing to trash their one-and-only partition, full of
>> data, to experiment with a new OS. Regular users don't
>> keep backups. Linux is the only UNIX-like OS that could
>> do a respectable job of running multi-user on vfat.
>
> The same thing can be (and is) done using initrd+loopback, with a lot
> less effort and all of the usual Unix filesystem semantics.
You don't get a shared filesystem that way. Windows would
not be able to see the files created by Linux. You'd get stuck
using the ext2 resizer all the time. You couldn't even move
a file from ext2 to vfat without having enough disk space for
it in both places.
On Sun, 2002-06-09 at 18:01, Albert D. Cahalan wrote:
> You don't get a shared filesystem that way. Windows would
> not be able to see the files created by Linux. You'd get stuck
> using the ext2 resizer all the time. You couldn't even move
> a file from ext2 to vfat without having enough disk space for
> it in both places.
That's not any different than having seperate VFAT and ext2 partitions
in a standard dual-boot situation.
- Nicholas
Nicholas Miell writes:
> On Sun, 2002-06-09 at 18:01, Albert D. Cahalan wrote:
>> You don't get a shared filesystem that way. Windows would
>> not be able to see the files created by Linux. You'd get stuck
>> using the ext2 resizer all the time. You couldn't even move
>> a file from ext2 to vfat without having enough disk space for
>> it in both places.
>
> That's not any different than having seperate VFAT and ext2
> partitions in a standard dual-boot situation.
Sure. That obviously sucks; Linux can do better.
It's important to make a transition to Linux as
painless as possible. Nobody considering an OS
change likes the feeling that their data files
are trapped on one side or the other.
I remember the screams when umsdos support was
dropped from most distributions. It would be
great to have a modern substitute for umsdos.
FAT32, NTFS, and HFS+ are what people get with
their hardware.
On Sun, 2002-06-09 at 18:58, Albert D. Cahalan wrote:
> > That's not any different than having seperate VFAT and ext2
> > partitions in a standard dual-boot situation.
>
> Sure. That obviously sucks; Linux can do better.
> It's important to make a transition to Linux as
> painless as possible. Nobody considering an OS
> change likes the feeling that their data files
> are trapped on one side or the other.
Huh? Windows can access files on VFAT and Linux can access files on
VFAT. How are they "trapped"?
- Nicholas
On 9 Jun 2002, Nicholas Miell wrote:
> On Sun, 2002-06-09 at 18:58, Albert D. Cahalan wrote:
> > > That's not any different than having seperate VFAT and ext2
> > > partitions in a standard dual-boot situation.
> >
> > Sure. That obviously sucks; Linux can do better.
> > It's important to make a transition to Linux as
> > painless as possible. Nobody considering an OS
> > change likes the feeling that their data files
> > are trapped on one side or the other.
>
> Huh? Windows can access files on VFAT and Linux can access files on
> VFAT. How are they "trapped"?
Because you are forbidding them to have symlink support.
In message "Re: vfat patch for shortcut display as symlinks for 2.4.18",
<<[email protected]>> wrote:
> > One can also live with "foo.lnk". (It's much easier and
> saner, too.)
>
> No one cannot untar a source tarball with symlinks in a vfat fs without
> the patch. We cannot live with foo.lnk. Its insane not to carry over the
> semantics as much as possible.
Does the proposed patch give full symlink support or does it just read .lnk
files? Most source tarballs will not have .lnk files in them, they will have
symlinks. Would tar create the .lnk files if it was extracting to vfat? If the
patch gives symlink support in some other way than .lnk files, why can't we just
use that and not meddle with reading the .lnk files to allow Linux to run in a
vfat partition.
> vfat is the only fs that can be shared between microsoft oses and linux.
> umsdos mangles filenames and does other ugly things. umsdos is an example
> of what not to do with a fs. umsdos is a hack. vfat+symlinks is the
> completion of an implementation.
This is why I think MS will (and are) killing FAT 32 as quickly as they can (the
last properly understood MS filesystem...). To really entice users from Windows
in the future, this kind of patch is going to have to work on NTFS, not FAT.
Now that the NT codebase is the "home" codebase as well (with the advent of XP),
NTFS is going to take massive inroads into FAT's market share. And there have
been rumours for a while that MS SQL Server is going to form the basis of the
next MS filesystem.
Joe.
+-------------------------------------------------+
| Joseph Mathewson <[email protected]> |
+-------------------------------------------------+
On Mon, Jun 10, 2002 at 07:42:03AM +0000, Joseph Mathewson wrote:
>
> Does the proposed patch give full symlink support or does it just read .lnk
> files? Most source tarballs will not have .lnk files in them, they will have
It provides read and write and create support, for the types that are
reasonably supportable. The description is on
http://www.fi.muni.cz/~adelton/linux/vfat-symlink/vfat-symlink.readme
and the patch is next to it.
> symlinks. Would tar create the .lnk files if it was extracting to vfat? If the
Right. The patch adds support for creating symlinks via .lnk files.
> patch gives symlink support in some other way than .lnk files, why can't we just
> use that and not meddle with reading the .lnk files to allow Linux to run in a
> vfat partition.
Well, because the .lnk approach in the patch is compatible both with
the Windows behaviour and the cygwin behaviour, you're getting rather
transparent symlink support.
> This is why I think MS will (and are) killing FAT 32 as quickly as they can (the
> last properly understood MS filesystem...). To really entice users from Windows
That may be true but the notebook I got last October came with Win ME
-- just FAT32, no NTFS. So they may be killing it but it's still
around and it will be for some time to come.
> in the future, this kind of patch is going to have to work on NTFS, not FAT.
> Now that the NT codebase is the "home" codebase as well (with the advent of XP),
> NTFS is going to take massive inroads into FAT's market share. And there have
> been rumours for a while that MS SQL Server is going to form the basis of the
> next MS filesystem.
Can't comment on that as I don't have NTFS handy. The patch makes it
possible to mount vfat aprtition in such a way that .lnk files are not
shown as a binary mess but as a symlink, the same way they look (from
user's perspective) in Windows and in cygwin.
--
------------------------------------------------------------------------
Jan Pazdziora | [email protected] | http://www.fi.muni.cz/~adelton/
... all of these signs saying sorry but we're closed ...
------------------------------------------------------------------------
On Sun, Jun 09, 2002 at 02:36:49PM -0700, Nicholas Miell wrote:
> >
> > WINE needs to be able to handle a symlink on ext2, so it can
> > damn well convert back. It's OK to give WINE some hack to get at
> > the content; it's not OK to hack bash to interpret .lnk files.
>
> Why would bash even want to interpret shortcut files? They're a proprietary,
> Windows-only format that have no real use beyond icons in the Start Menu
> or on the desktop. Hacking the filesystem to treat something that
Well, you could say that about FAT as well.
> fundamentally is not a symlink as a symlink is even stupider than
> hacking bash to do the same thing.
The symlink file can have more functions as you have stated, and one
of them is symlink. It works in Windows and it works in cygwin. Support
for symlinks on vfat is similar to long names, for example -- you
could live with abbreviations but it's reasonable to be compatible
with the other party.
> > One can live with an occasional broken symlink:
> > "foo" --> "[UNIMPLEMENTED LINK TYPE]"
>
> One can also live with "foo.lnk". (It's much easier and saner, too.)
It's not. The content of the file is not nicely readable. And
operation done on the file in Windows and on Linux (like writing the
file) now differs because Windows (and cygwin) follow the symlink
while Linux with vfat mounted does not.
> > > Finally, I haven't seen any justification for why symlinks on VFAT are
> > > needed, beyond some vague statements that it's useful when dual booting.
Similar reason why the vfat support is in, isn't it? :-)
> > > Face it, VFAT isn't a Unix filesystem and introducing ugly hacks to make
> > > it more similar to one will only cause problems in the long run. If you
> > > want symlinks, use a real filesystem or use umsdos on your favorite FAT
> > > filesystem. (Assuming that umsdos still works...).
It's not "want symlinks", it's more like "want similar behaviour" and
"be compatible".
--
------------------------------------------------------------------------
Jan Pazdziora | [email protected] | http://www.fi.muni.cz/~adelton/
... all of these signs saying sorry but we're closed ...
------------------------------------------------------------------------
On Sun, Jun 09, 2002 at 03:02:10PM -0700, [email protected] wrote:
>
> Only the .lnk files that can be properly interpreted as symlinks are
> showing up as symlink as far as I can tell. This is quite ok and very
Right.
> helpful. .lnk file interpretation can be switched off and on as a boot
> option.
Umm, mount option.
> vfat with the patch can *create* symlinks that are compatible with other
> oses.
>
> The patch is a must have ....
I'll try to update the patch for latest kernel versions so that we're
talking current code.
Yours,
--
------------------------------------------------------------------------
Jan Pazdziora | [email protected] | http://www.fi.muni.cz/~adelton/
... all of these signs saying sorry but we're closed ...
------------------------------------------------------------------------
Hi,
On Mon, 10 Jun 2002, Joseph Mathewson wrote:
> And there have been rumours for a while that MS SQL Server is going to
> form the basis of the next MS filesystem.
No problem. I've had a patch back in the 2.0 days, I believe, that
provided a mountable filesystem that came out of Ingres SQL server. (But
anyway, 2.0 is gone, Ingres is either, and the patch seems, too.)
Regards,
Thunder
--
German attitude becoming | Thunder from the hill at ngforever
rightaway popular: |
"Get outa my way, | free inhabitant not directly
for I got a mobile phone!" | belonging anywhere
On Mon, 10 Jun 2002, Joseph Mathewson wrote:
> Does the proposed patch give full symlink support or does it just read
> .lnk files? Most source tarballs will not have .lnk files in them,
> they will have symlinks. Would tar create the .lnk files if it was
> extracting to vfat? If the patch gives symlink support in some other
> way than .lnk files, why can't we just use that and not meddle with
> reading the .lnk files to allow Linux to run in a vfat partition.
Full symlink support. Yes, tar creates symlinks and the vfat fs makes .lnk
files out of the symlinks. when ls displays the directory contents the
vfat fs recognizes the .lnk files and tells the os that there is a
symlink. Its fully transparent. The .lnk files are only visible
under windoze.
[email protected] wrote:
> Full symlink support. Yes, tar creates symlinks and the vfat fs makes .lnk
> files out of the symlinks. when ls displays the directory contents the
> vfat fs recognizes the .lnk files and tells the os that there is a
> symlink. Its fully transparent. The .lnk files are only visible
> under windoze.
the paths in windows looked like this:
c:\folder\file
thus, under linux, all the links would be broken links anyway (and vice
versa).
Banka.
On Tue, 11 Jun 2002, Banka wrote:
> [email protected] wrote:
>
> the paths in windows looked like this:
> c:\folder\file
>
> thus, under linux, all the links would be broken links anyway (and vice
> versa).
See the readme.
This looks like a bad idea. The reason is that the VFAT driver is the
wrong abstraction layer to support the '.lnk' files:
* on Windows if you open("foo.lnk") you get the .lnk file, not the file
it 'links' to. On Linux you would get the file it points to instead
which is a different behavior.
* Windows supports .lnk files on FAT, VFAT, NTFS, ISO9660, etc. So if
such support is added in the Linux kernel, it should be added to all of
the above filesystems. And then, there is no reason not to add it to
ext2, NFS, etc!
Other issues:
* what happens if a Unix program tries to create a file called
'foo.lnk' that is not a .lnk file? I could create a text file called
'mylinks.lnk' to store bookmark stuff for instance.
* there is no such thing as a dead .lnk file. If the specified path is
not found, Windows will use the file date, file size and whatnot to try
to find where the target went. Is it planned to add any such support
planned?
* it has been mentionned that this makes it possible to extract source
tarballs that contain symlinks on a VFAT filesystem. While this sounds
cool I am not sure it is so useful.
- for VFAT one could use the UMSDOS filesystem to do the same thing,
and get many other features at the same time (at least while in
Linux)
- again, if it is useful on VFAT, then it would be useful for CD+RW
filesystems (UDF?) (e.g. for archival), on NTFS (assuming write is
well supported one day, etc.
- if you switch back to Windows, no compiler is going to be able to
use the '.lnk' files. That's because no compilers that I know of
uses shell32.dll to read source files. So this would only work
while on the Linux side and maybe in cygwin too.
This would also hurt Wine as:
* it would prevent wine from reading the information in the '.lnk'
file... at least for 'supported' '.lnk' files
* it's not entirely clear to me what is done with unsupported '.lnk'
files. Are they just dead symlinks (again !=windows) or can one read
their contents? In the first case Wine is dead in the water again, and
in the latter case we'll have to play games to know which kind we got.
* it was suggested to implement a hack to let Wine access the '.lnk'
data. Why implement a hack which is going to be Linux specific when
doing nothing works just fine and on any Unix system? Plus this is going
to require Linux specific code in Wine if it is to be supported.
* making it an option does not help Wine at all, especially if it is a
default one. Then we have to keep telling users that they have to modify
their fstab if they want Wine to work.
The right level to implement symlink support is:
* in Wine. Of course! There we know what the drive mappings are, we
have access to the registry and can even use the native shell library.
* in an LD_PRELOAD library. Then they would work for all filesystems,
be selectable on a per-user or even per-process basis. Of course it
would most likely not work with Wine (ld_preload libraries seldom do)
but we can at least easily disable such libraries using a wrapper
script.
* as an option in the KDE/Gnome file browsers and related file access
methods. That's the layer which seems closest to the Windows shell
'layer'.
This looks like it could be the next 'unhide' thing. See:
* isofs unhide option: troubles with Wine
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0205.3/0267.html
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0206.0/0411.html
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0206.1/0246.html
--
Francois Gouget [email protected] http://fgouget.free.fr/
Linux: It is now safe to turn on your computer.
Francois Gouget writes:
> This looks like a bad idea. The reason is that the VFAT driver is the
> wrong abstraction layer to support the '.lnk' files:
>
> * on Windows if you open("foo.lnk") you get the .lnk file, not the file
> it 'links' to. On Linux you would get the file it points to instead
> which is a different behavior.
That's a common Windows app bug which exists exactly because
the Microsoft implementation is at the wrong abstraction layer.
> * Windows supports .lnk files on FAT, VFAT, NTFS, ISO9660, etc. So if
> such support is added in the Linux kernel, it should be added to all of
> the above filesystems. And then, there is no reason not to add it to
> ext2, NFS, etc!
As long as a default ext2 mount doesn't get hit, I won't complain.
> * what happens if a Unix program tries to create a file called
> 'foo.lnk' that is not a .lnk file? I could create a text file called
> 'mylinks.lnk' to store bookmark stuff for instance.
You get about the same as when creating ":" I'd imagine.
> * there is no such thing as a dead .lnk file. If the specified path is
> not found, Windows will use the file date, file size and whatnot to try
> to find where the target went. Is it planned to add any such support
> planned?
I really doubt that! Calling out to userspace, as kmod and the
hotplug stuff do, might be... not extremely unreasonable.
> * it has been mentionned that this makes it possible to extract source
> tarballs that contain symlinks on a VFAT filesystem. While this sounds
> cool I am not sure it is so useful.
> - for VFAT one could use the UMSDOS filesystem to do the same thing,
> and get many other features at the same time (at least while in
> Linux)
not Cygwin compatible
> * it would prevent wine from reading the information in the '.lnk'
> file... at least for 'supported' '.lnk' files
It's fixable.
> * it was suggested to implement a hack to let Wine access the '.lnk'
> data. Why implement a hack which is going to be Linux specific when
> doing nothing works just fine and on any Unix system? Plus this is going
> to require Linux specific code in Wine if it is to be supported.
Wine already has Linux-specific code. The "doing nothing" option
doesn't get us what we want: symlinks.
> * making it an option does not help Wine at all, especially if it is a
> default one. Then we have to keep telling users that they have to modify
> their fstab if they want Wine to work.
Making it an option is NOT to help Wine, except perhaps as
a temporary work-around until Wine is updated.
> The right level to implement symlink support is:
>
> * in Wine. Of course! There we know what the drive mappings are, we
> have access to the registry and can even use the native shell library.
This won't help with compiling Linux on a vfat partition which
happens to have plenty of free space for a big compile.
This won't help make a vfat root work.
> * in an LD_PRELOAD library. Then they would work for all filesystems,
> be selectable on a per-user or even per-process basis. Of course it
> would most likely not work with Wine (ld_preload libraries seldom do)
> but we can at least easily disable such libraries using a wrapper
> script.
This is the TOTAL CRAP option. Clearly you've never used LD_PRELOAD.
You're not going to get that working with static linked executables,
setuid, setgid, very old executables, very new executables, stuff
written in FreePascal, etc., etc., etc.
> * as an option in the KDE/Gnome file browsers and related file access
> methods. That's the layer which seems closest to the Windows shell
> 'layer'.
Does anybody actually use a GUI file browser??? Eeeew.
Hacking everything from awk to zsh would be required.
> This looks like it could be the next 'unhide' thing. See:
That was botched.
1. no backdoor
2. no Wine patch to use the backdoor
The info really needs to be passed via stat() and
the directory reading calls, same as we do for the
file type info today. Then JFS, NTFS, FAT, and many
other filesystems could use it.
On Tue, 11 Jun 2002, Albert D. Cahalan wrote:
> Francois Gouget writes:
>
> > This looks like a bad idea. The reason is that the VFAT driver is the
> > wrong abstraction layer to support the '.lnk' files:
> >
> > * on Windows if you open("foo.lnk") you get the .lnk file, not the file
> > it 'links' to. On Linux you would get the file it points to instead
> > which is a different behavior.
>
> That's a common Windows app bug which exists exactly because
> the Microsoft implementation is at the wrong abstraction layer.
No it is not a 'Windows app bug' bug. It is you who are mistaken because
you persist in believing that .lnk files are or are meant to be symbolic
links. They are not.
Unix has the exact equivalent to .lnk files. These are the '.dsektop'
files used by KDE and Gnome (they even used to be called '.kdelnk' files
in KDE 1).
Look at all the similarities:
* both may contain a path to another file
* both may contain a command to be executed when clicked upon
* for both, the above command may include command line options and that
can even take a filename as a parameter (e.g. for drag and drop)
* both let you specify the directory the above command is to be
executed into
* both usually contain a reference to an icon
* both are used by the 'desktop' layer to implement the desktop menus
(Start Menu, KDE Start, Gnome foot menu) and icons
The differences are very minor:
* '.lnk' files can reference objects that do not exist in the
filesystem. This seems to be a relatively recent addition and I am not
sure that '.desktop' files have a similar concept
* the format of '.lnk' files is binary while the '.desktop' files are
text files
* the '.desktop' files are also used to handle MIME type associations
by KDE but not Gnome (uses '.mime' and '.keys' files) and not Windows
(uses the registry)
See below for more information about '.desktop' files:
http://webcvs.kde.org/cgi-bin/cvsweb.cgi/~checkout~/kdelibs/kio/DESKTOP_ENTRY_STANDARD?rev=1.9
So as you see '.lnk' are the exact equivalent of '.desktop' files on
Unix.
* Thus, saying that not dereferencing '.lnk' files is a 'common Windows
app bug' is equivalent to saying that gcc is buggy because it does not
dereference '.desktop' files.
* Saying that it is because 'because the Microsoft implementation is at
the wrong abstraction layer' is equivalent to saying that '.desktop'
files are at the wrong abstraction layer and should have been
implemented as symbolic links.
* And converting between '.lnk' files and symbolic links in the VFAT
driver is equivalent to converting between '.desktop' files and symbolic
links in the ext2 driver.
Let's face it, Windows simply does not have anything like symbolic
links. Now you can highjack the concept of '.lnk' files to compensate
for that, but this is going to be a kludge of your doing. So don't
complain about Microsoft doing '.lnk' files wrong.
Now, assuming that it does get implemented.
* Is there going to be *any* '.lnk' files created by Windows that are
going to be correctly converted to symbolic links? As far as I can tell
there are types of '.lnk' files:
- absolute path 'x:\...'
-> not supported because of the drive conversion issue
- UNC paths of the form '\\host\share\...'
-> not supported if host != localhost
-> if local they will be of the form '\\localhost\X\...' where X is
a drive letter. So they will not be supported either (or am I wrong
here?)
- commands with parameters
-> not supported. Plus the command probably contains a drive letter
and would not be executable without Wine anyway
- references to objects not in the filesystem (e.g. 'My Computer')
-> not supported
- relative paths
-> as far as I know Windows does not create any such '.lnk' file.
If I am wrong. how does one create such a .lnk file?
* Is this going to be the default or just an option? Given that this
seems only useful in corner cases and has the potential to cause a lot
of trouble, I sure hope it is not going to be the default. You yourself
would oppose a similar option if it were the default on the ext2
filesystem.
* Still assuming that this gets implemented, I would also like that
plans are made to make it possible for Wine to get access to the content
of these files. So what would be the API for doing so?
[...]
> This is the TOTAL CRAP option. Clearly you've never used LD_PRELOAD.
> You're not going to get that working with static linked executables,
> setuid, setgid, very old executables, very new executables, stuff
> written in FreePascal, etc., etc., etc.
I know all the problems caused by LD_PRELOAD. xalf, aRts and ESounD all
use it for various purposes and they all cause problems. However, there
are so few situations where what you propose seems useful that it might
just be enough to take care of the issue. But I will grant you that it
is definitely not a general purpose solution.
Besides buying a larger disk (include the obligatory 'pretty cheap these
days'), repartitionning, loopback filesystems which I agree all have
their drawbacks, wouldn't the best solution (given the above) be to use
UMSDOS?
It seems to me that UMSDOS does a much better job at making a VFAT
partition usable as a Unix filesystem:
* supports symbolic links of course
* also supports hard links
* supports ownership and permissions which if you are going to
regularly use it would be a good thing to have
* supports socket files (for AF_LOCAL servers, useful if your
WinePrefix points to that partition for instance)
* even supports device files
They even mention the exact scenario you are facing:
http://www.tldp.org/HOWTO/UMSDOS-HOWTO-8.html
And if there is any issue with UMSDOS, then I think it would be more
useful to fix these issues than to hack .lnk files.
> > This looks like it could be the next 'unhide' thing. See:
>
> That was botched.
>
> 1. no backdoor
> 2. no Wine patch to use the backdoor
2. is redundant as it follows from 1. Obviously not Wine's fault.
--
Francois Gouget [email protected] http://fgouget.free.fr/
Advice is what we ask for when we already know the answer but wish we didn't
-- Eric Jong
Also sprach Francois Gouget:
>
> On Tue, 11 Jun 2002, Albert D. Cahalan wrote:
>
> > Francois Gouget writes:
> >
> > > This looks like a bad idea. The reason is that the VFAT driver is
> > > the wrong abstraction layer to support the '.lnk' files:
> > >
> > > * on Windows if you open("foo.lnk") you get the .lnk file, not
> > > the file
> > > it 'links' to. On Linux you would get the file it points to
> > > instead which is a different behavior.
> >
> > That's a common Windows app bug which exists exactly because
> > the Microsoft implementation is at the wrong abstraction layer.
>
> No it is not a 'Windows app bug' bug. It is you who are mistaken
> because you persist in believing that .lnk files are or are meant to
> be symbolic links. They are not.
>
> Unix has the exact equivalent to .lnk files. These are the '.dsektop'
> files used by KDE and Gnome (they even used to be called '.kdelnk'
> files in KDE 1).
These files *are not* Unix files in the sense that they have universally
understood or generally accepted semantics. They are artifacts of KDE and
GNOME and the window managers I use do not know how to interpret them,
except as plain vanilla text files.
Kurt
--
Canada Bill Jone's Motto:
It's morally wrong to allow suckers to keep their money.
Supplement:
A .44 magnum beats four aces.
On Wed, 12 Jun 2002, Kurt Wall wrote:
> > Unix has the exact equivalent to .lnk files. These are the '.dsektop'
> > files used by KDE and Gnome (they even used to be called '.kdelnk'
> > files in KDE 1).
>
> These files *are not* Unix files in the sense that they have universally
> understood or generally accepted semantics. They are artifacts of KDE and
What the hell do you mean "these files are not Unix files"??? They do
have universally understood semantics - persistent named array of characters.
That's what Unix files _are_.
> GNOME and the window managers I use do not know how to interpret them,
> except as plain vanilla text files.
Yes, and...? From what I've seen in this thread that's precisely what
these .lnk files are in Windows. You would have a point if Windows
kernel would handle them as Unix kernel handles symlinks. It doesn't.
Some libraries know how to parse them. Which means "plain files", no
matter how you turn it.
My $0.02. Read the quote, as Francois has been so kind as to make most of it for me:
At 07:31 AM 6/11/2002 -0700, Francois wrote:
{note that I have snipped parts unrelated to my argument}
>This looks like a bad idea. The reason is that the VFAT driver is the
>wrong abstraction layer to support the '.lnk' files:
>
> * Windows supports .lnk files on FAT, VFAT, NTFS, ISO9660, etc. So if
>such support is added in the Linux kernel, it should be added to all of
>the above filesystems. And then, there is no reason not to add it to
>ext2, NFS, etc!
>
>Other issues:
>
> * it has been mentionned that this makes it possible to extract source
>tarballs that contain symlinks on a VFAT filesystem. While this sounds
>cool I am not sure it is so useful.
> - for VFAT one could use the UMSDOS filesystem to do the same thing,
> and get many other features at the same time (at least while in
> Linux)
> - again, if it is useful on VFAT, then it would be useful for CD+RW
> filesystems (UDF?) (e.g. for archival), on NTFS (assuming write is
> well supported one day, etc.
>
>This would also hurt Wine as:
>
> * it would prevent wine from reading the information in the '.lnk'
>file... at least for 'supported' '.lnk' files
man 2 readlink
What's stopping us from adding an expanded version?
> * it was suggested to implement a hack to let Wine access the '.lnk'
>data. Why implement a hack which is going to be Linux specific when
>doing nothing works just fine and on any Unix system? Plus this is going
>to require Linux specific code in Wine if it is to be supported.
(see above)
-----
I am in full agreement with Francois' postulation; the VFAT driver is the wrong place to support these things. For one thing, it would be very nice to support these same symlinks on NTFS; however, unnecessary duplication of code is, if I recall correctly, a Bad Thing(TM). I believe that the correct place for this support is in the VFS. Now, hear me out -- what I'm advocating will probably sound absolutely nuts to some of you guys ("I am NOT polluting the entire VFS with that $#!+ from Redmond!") -- but I actually have (what I think is) a good reason.
The first thing we need to do is ignore the origins. That means ignoring that the source of this discussion is from Redmond. Nobody here has any *major* gripes with the BSD people (compared a certain other OS), do they?
Let's say, just for theory's sake, that BSD 6 came out yesterday.
With it came a brand new type of symlink. Instead of relying on some special bitflag in the inode (as it appears on disk, anyway) to mark these symlinks as such, they are instead regular files that are marked as symlinks by the last four characters in the filename being ".lnk".
This new method of storing symlinks is extremely useful -- it allows one to create symlinks on a number of filesystems that you couldn't before, because those filesystems have nowhere to store a 'S_IFLNK' flag.
Linux is about versatility; you have hardware, we'll run on it... we support TiVo hard drives! Likewise, if you have software, we'll run it. You can even get another program ("Wine") that will run programs for a particularly popular desktop operating system! So if this theoretical OS ("BSD 6") supports this extremely flexible type of symlink, why shouldn't we? Hmm?
Now comes my argument for putting it into the VFS.
-- Some other arguments (and my counters)
Some have argued that we should hack around userspace programs for this to happen. This is fine with me; get back to me when you've patched every single program in existence that accesses files (other than via stdin/stdout).
Some of the same people have argued that adding this sort of thing to *any* layer in Linux would break a popular program called Wine. Wine will break because it uses the above method (hack userspace to make it work). Thus, this argument sounds like "well... we did it this way before, so we should continue doing it this way, because if we change it, we'll have to redo what we already have." If everybody used that line of logic, we'd still be using punch cards, because switching to floppy drives would force us to convert all the punch card data into floppy disks.
There comes a time when we will have to break userspace in order to progress forward; that time is called "the 2.5 series".
---
We (well, some of us) want to be able to support these ".lnk" files in both VFAT and NTFS (and GodKnowsWhatFS in the future). Therefore, it would be good to have the 'lnk' translation at a higher level than the filesystem driver; this could make it possible to automatically support '.lnk' files on other filesystems, without directly injecting the code to support it into those filesystems. The VFS is a layer directly above every filesystem!
Some of us don't want this .lnk garbage! Some of us hate it! Don't muck with MY filesystem! For this, we'd want a mount option to disable this. The VFS already has support for certain global mount options -- the two that come to mind are 'ro' and 'rw'.
root@whisper:~# mount /dev/hda3 -t vfat -o lnk
Some of us want to be able to directly access these '.lnk' files.
man 2 readlink
man 2 lstat
All we need is forms of these that can treat treat these '.lnk' files as true files. Or perhaps a new "openlink" would be more appropriate, allowing direct read/write access.
The VFS is in a perfect position to intercept accesses to files ending in '.lnk' and do symlink-like translation.
And if you hate it all, well, just #define CONFIG_WYNLINKS N. I don't need framebuffer support in my headless linux server -- you don't see me lobbying against its inclusion in mainline, do you?
--
Stevie-O
Real programmers use COPY CON PROGRAM.EXE
Also sprach Alexander Viro:
>
> On Wed, 12 Jun 2002, Kurt Wall wrote:
>
> > > Unix has the exact equivalent to .lnk files. These are the
> > > '.dsektop' files used by KDE and Gnome (they even used to be
> > > called '.kdelnk' files in KDE 1).
> >
> > These files *are not* Unix files in the sense that they have
> > universally understood or generally accepted semantics. They are
> > artifacts of KDE and
>
> What the hell do you mean "these files are not Unix files"??? They do
> have universally understood semantics - persistent named array of
> characters. That's what Unix files _are_.
That's *precisely* the point I tried to make. .desktop files are just
plain text files, as far as Unix is concerned. They do not map neatly
to Windows .lnk files because the kernel's file system layer does
not handle them specially, as it does symlinks. God and Bill Gates
alone know how Windows handles .lnk files, but it does seem that Windows
imputes to them special semantics, rather like a shell script.
> > GNOME and the window managers I use do not know how to interpret
> > them, except as plain vanilla text files.
>
> Yes, and...? From what I've seen in this thread that's precisely what
> these .lnk files are in Windows. You would have a point if Windows
> kernel would handle them as Unix kernel handles symlinks. It doesn't.
Again, that was my point, which I rather muddled. I was coming at it from
the other direction, though. Windows doesn't handle .lnks as the Unix kernel
handles symlinks, true, but the kernel doesn't handle .desktop files as
Windows handles .lnks, either.
> Some libraries know how to parse them. Which means "plain files", no
> matter how you turn it.
Quite so: the kernel sees .desktop and sees a plain old file; Windows sees
.lnk and does something that resembles interpreting them. Again, my point
was that .desktop files do not map cleanly .lnk files.
As for who "wins" in this thread, I could care less because I don't need
or want to display Windows shortcuts.
Kurt
--
Pity the meek, for they shall inherit the earth.
-- Don Marquis
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On June 12, 2002 19:25, Kurt Wall wrote:
> That's *precisely* the point I tried to make. .desktop files are just
> plain text files, as far as Unix is concerned. They do not map neatly
> to Windows .lnk files because the kernel's file system layer does
> not handle them specially, as it does symlinks. God and Bill Gates
> alone know how Windows handles .lnk files, but it does seem that Windows
> imputes to them special semantics, rather like a shell script.
No, some people actually know how Windows works. The kernel has very little to
do with .lnk files, and in fact it sees them as regular files. If you run
"notepad foo.lnk", you will see the link's binary contents. If you use the
CreateFile or OpenFile kernel calls, you will get a file handle pointing to
the link's contents. If you attempt to execute a .lnk file from the command
line or using CreateProcess, it will horribly fail.
In fact, to dereference a link in userspace, you must open the .lnk file,
examine its contents with a library call, and then open the destination file.
This is extremely similar to how Gnome or KDE handle .desktop files: mainly
in the shell.
- -Ryan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE9CAawLGMzRzbJfbQRAm05AJ4gUYliitP5APHO/IM5jPB7wukGCgCgoPFg
qGH7VCkKap7mSFAET9T3n88=
=5Oer
-----END PGP SIGNATURE-----
Also sprach Ryan Cumming:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On June 12, 2002 19:25, Kurt Wall wrote:
> > That's *precisely* the point I tried to make. .desktop files are
> > just plain text files, as far as Unix is concerned. They do not map
> > neatly to Windows .lnk files because the kernel's file system layer
> > does not handle them specially, as it does symlinks. God and Bill
> > Gates alone know how Windows handles .lnk files, but it does seem
> > that Windows imputes to them special semantics, rather like a shell
> > script.
>
> No, some people actually know how Windows works. The kernel has very
> little to do with .lnk files, and in fact it sees them as regular
> files. If you run "notepad foo.lnk", you will see the link's binary
> contents. If you use the CreateFile or OpenFile kernel calls, you will
> get a file handle pointing to the link's contents. If you attempt to
> execute a .lnk file from the command line or using CreateProcess, it
> will horribly fail.
>
> In fact, to dereference a link in userspace, you must open the .lnk
> file, examine its contents with a library call, and then open the
> destination file. This is extremely similar to how Gnome or KDE
> handle .desktop files: mainly in the shell.
Okay. I readily admit that I do not know how Windows works.
I stand corrected.
Kurt
--
Happiness, n.:
An agreeable sensation arising from contemplating the misery of
another.
-- Ambrose Bierce, "The Devil's Dictionary"
On Wed, 12 Jun 2002, Kurt Wall wrote:
> Also sprach Alexander Viro:
[...]
> > What the hell do you mean "these files are not Unix files"??? They do
> > have universally understood semantics - persistent named array of
> > characters. That's what Unix files _are_.
>
> That's *precisely* the point I tried to make. .desktop files are just
> plain text files, as far as Unix is concerned. They do not map neatly
> to Windows .lnk files because the kernel's file system layer does
> not handle them specially, as it does symlinks. God and Bill Gates
> alone know how Windows handles .lnk files, but it does seem that Windows
> imputes to them special semantics, rather like a shell script.
Well, you should go talk to Wine hackers one day. More is known about
.lnk files than you think.
The Windows kernel has nothing to do with them. If you want to
dereference .lnk files you have to call a regular user-space library,
more specifically the shell32.dll library. For more information, see the
IShellLink COM interface:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/reference/ifaces/ishelllink/ishelllink.asp
So .lnk files are handled 100% in userspace, just like .desktop files.
[snipping rest of email which is moot]
--
Francois Gouget [email protected] http://fgouget.free.fr/
tcA thgirypoC muinelliM latigiD eht detaloiv tsuj evah uoY
On Wed, 12 Jun 2002, Kurt Wall wrote:
> Quite so: the kernel sees .desktop and sees a plain old file; Windows sees
> .lnk and does something that resembles interpreting them. Again, my point
> was that .desktop files do not map cleanly .lnk files.
"Windows" as in...? AFAICS Windows _kernel_ sees .lnk and sees a plain old
file. Some part of godforsaken mess known as GNOME asks kernel to read
from plain old file and interprets the contents returned by read(). Some
part of godforsaken mess known as Windows userland asks kernel to read from
plain old file and interprets the contents returned by read(). In either
case interpretation is done in userland.
I don't see any reason to put that stuff into the kernel - no more than
putting ~-expansion or globbing in there.
On Wed, 12 Jun 2002, Stevie O wrote:
[...]
> With it came a brand new type of symlink. Instead of relying on some
> special bitflag in the inode (as it appears on disk, anyway) to mark
> these symlinks as such, they are instead regular files that are marked
> as symlinks by the last four characters in the filename being ".lnk".
>
> This new method of storing symlinks is extremely useful -- it allows
> one to create symlinks on a number of filesystems that you couldn't
> before, because those filesystems have nowhere to store a 'S_IFLNK'
> flag.
[...]
> Now comes my argument for putting it into the VFS.
Yes, this would be much more useful. Mainly because it would make it
usable on more filesystems: VFAT, NTFS, ISO9660, etc.
However, since files with the .lnk extension are already widely
used and have strictly nothing to do with the notion of symbolic
links, I would propose the following modifications:
* first use another distinguishing feature to recognize these files.
The goal is to minimize the risk of interference with normal legitimate
files.
* use of weird characters comes to mind but compatibility with a wide
range of filesystems restricts choices
* using .desktop as the extension is of course definitely eliminated
* since this has strictly nothing to do with .lnk files the format of
these files can be very simple: just the destination file name
> Some of us don't want this .lnk garbage! Some of us hate it! Don't
> muck with MY filesystem! For this, we'd want a mount option to disable
> this. The VFS already has support for certain global mount options --
> the two that come to mind are 'ro' and 'rw'.
>
> root@whisper:~# mount /dev/hda3 -t vfat -o lnk
I propose 'slnk' as the name of the option as an abreviation of
'symbolic link'. This way later one can add an 'hlnk' option for hard
links though I very much doubt this would be feasible.
(and no, 'slnk' has nothing to do with '.lnk' files ;-)
> And if you hate it all, well, just #define CONFIG_WYNLINKS N.
Agreed. Most users will be quite happy with regular symbolic links
so making this a compile option is a good thing.
Now, why not generalize a bit and redo UMSDOS stackable filesystem that
would work on top of any other filesystem?
('stackable filesystem', does that exist on Linux?)
What I mean by that is when you try to create a symbolic link (for
instance), the request would be handled by this 'virtual' filesystem. It
would do tricks ala UMSDOS, and pass the appropriate requests down to
the underlying filesystem driver, be that VFAT, NTFS or ISO9660.
There might be issues like how to identify a given file correctly in a
way which is independent from the underlying filesystem (e.g. I believe
there's no inode on NTFS), and I am not sure what a mount entry would
look like (maybe vufs defaults,dev=/dev/hda1,fs=vfat,nouser), But if
these issues could be resolved, it would give you a filesystem with the
full Unix semantics.
--
Francois Gouget [email protected] http://fgouget.free.fr/
Computers are like airconditioners
They stop working properly if you open WINDOWS
> - for VFAT one could use the UMSDOS filesystem to do the same thing,
> and get many other features at the same time (at least while in
> Linux)
AFAIK, umsdos doesn't work on top of fat32, which makes it practically
unusable in 2002.
T.
On Wed, 12 Jun 2002, Francois Gouget wrote:
> On Wed, 12 Jun 2002, Stevie O wrote:
> [...]
> > With it came a brand new type of symlink. Instead of relying on some
> > special bitflag in the inode (as it appears on disk, anyway) to mark
> > these symlinks as such, they are instead regular files that are marked
> > as symlinks by the last four characters in the filename being ".lnk".
> >
> > This new method of storing symlinks is extremely useful -- it allows
> > one to create symlinks on a number of filesystems that you couldn't
> > before, because those filesystems have nowhere to store a 'S_IFLNK'
> > flag.
> [...]
> > Now comes my argument for putting it into the VFS.
>
> Yes, this would be much more useful. Mainly because it would make it
> usable on more filesystems: VFAT, NTFS, ISO9660, etc.
Vetoed. Consider what happens if you rename such file, for one thing.
At 12:09 AM 6/13/2002 -0400, Alexander Viro wrote:
>Vetoed. Consider what happens if you rename such file, for one thing.
I don't understand
What do you mean, if I rename such a file?
--
Stevie-O
Real programmers use COPY CON PROGRAM.EXE
On Thu, 13 Jun 2002, Stevie O wrote:
> At 12:09 AM 6/13/2002 -0400, Alexander Viro wrote:
> >Vetoed. Consider what happens if you rename such file, for one thing.
>
> I don't understand
> What do you mean, if I rename such a file?
rename("foo.lnk", "foo");
or other way round. Especially funny if you already have file opened.
On Thu, 13 Jun 2002, Alexander Viro wrote:
>
>
> On Thu, 13 Jun 2002, Stevie O wrote:
>
> > At 12:09 AM 6/13/2002 -0400, Alexander Viro wrote:
> > >Vetoed. Consider what happens if you rename such file, for one thing.
> >
> > I don't understand
> > What do you mean, if I rename such a file?
>
> rename("foo.lnk", "foo");
Let's not use .lnk as the extension, ok? It's an area that is still
quite sensitive <g>
So let's say that we use .!nk as the extension of our brand new symlink
implementation (assuming using '!' is ok).
Then here is how it would work:
* if the user creates a symlink called "foo", we create a file called
"foo.!nk" on the underlying filesystem.
* opendir+readdir does not return "foo.!nk" but instead returns "foo"
* open("foo") opens the symlink, i.e. the VFS reads "foo.!nk" and open
the filename contained therein
* create("bar.!nk") is not allowed: on such a filesystem, you are not
allowed to create any file ending with ".!nk"
* symlink(...,"...very long name") fails if the filename is too long
for VFS to append ".!nk"
* etc.
So there are definitely limitations but I believe it could work. I am
not going to argue that it should be done though as I am happy enough
with the current situation (and it's not like I have the time to work on
it either).
--
Francois Gouget [email protected] http://fgouget.free.fr/
La terre est une b?ta...
On Thu, 13 Jun 2002, Francois Gouget wrote:
> On Thu, 13 Jun 2002, Alexander Viro wrote:
>
> >
> >
> > On Thu, 13 Jun 2002, Stevie O wrote:
> >
> > > At 12:09 AM 6/13/2002 -0400, Alexander Viro wrote:
> > > >Vetoed. Consider what happens if you rename such file, for one thing.
> > >
> > > I don't understand
> > > What do you mean, if I rename such a file?
> >
> > rename("foo.lnk", "foo");
>
> Let's not use .lnk as the extension, ok? It's an area that is still
> quite sensitive <g>
>
> So let's say that we use .!nk as the extension of our brand new symlink
> implementation (assuming using '!' is ok).
>
> Then here is how it would work:
> * if the user creates a symlink called "foo", we create a file called
> "foo.!nk" on the underlying filesystem.
> * opendir+readdir does not return "foo.!nk" but instead returns "foo"
> * open("foo") opens the symlink, i.e. the VFS reads "foo.!nk" and open
> the filename contained therein
> * create("bar.!nk") is not allowed: on such a filesystem, you are not
> allowed to create any file ending with ".!nk"
> * symlink(...,"...very long name") fails if the filename is too long
> for VFS to append ".!nk"
> * etc.
I don't see where VFS would come into the game - what you had described
is behaviour of ->symlink() and ->lookup() of filesystem in question.
For VFS name components are arbitrary sequences of characters other than
'\0' and '/'. Period. It has no idea of extensions, maximal component
lengths, etc.
Moreover, names returned by ->readdir() are not interpreted - they are
responsibility of filesystem in question. Ditto for limits you place
on the names acceptable for ->create(), ->mkdir(), etc. - it's up to
filesystem.
Same goes for the way you store and interpret symlinks - VFS has no
business messing with that; that's what ->readlink() and ->follow_link()
are for.
_If_ you want to use "add magical 4 bytes to the end of component to
indicate a symlink" - more power to you, but that's nothing but a
detail of your filesystem layout. You are making a directory with
both 'foo' and 'foo.!nk' invalid, but that's the matter of fsck for
your filesystem and ability of fs driver to cope with such error
gracefully.
I don't see why anyone would want to do that, but it's certainly doable.
Obviously if you do that for several filesystems and find that some
code is shared, you can put the common helpers into a library and use
them instead of duplicating that code. I doubt that there would be
that much sharing possible, though.
What I _don't_ want to see is "let's add magical API for reading and
writing these objects" or "let's add a flag telling to VFS that fs
uses that representation of symlinks and make it do the magic". In
particular, if lookup for "foo" gives you such symlink, lookup for
"foo.!nk" should fail rather than giving you access to "raw" object -
just to forestall the obvious first bogus proposal.
Frankly, I still don't see why anyone would want to use VFAT other than for
ZIP drives / floppies / flash (i.e. shared removable media for transfering
data to/from non-Unix hosts), so I don't see any value in doing symlinks
on VFAT at all, but as long as this weirdness is confined to filesystem
code and plays nice with API - it's none of my problems; take it with
VFAT maintainer. As soon as it stops being private fs business, though...
> Do people who'd want this even still exist? I don't even know if I'd be
> able to fix it, but hey, it's summer, and I have not much of anything
> better to do.
Judging by the heat in this thread, I would think there could be a few
interested folks.
T.
At 05:18 AM 6/13/2002 -0400, Alexander Viro wrote:
>I don't see where VFS would come into the game - what you had described
>is behaviour of ->symlink() and ->lookup() of filesystem in question.
>For VFS name components are arbitrary sequences of characters other than
>'\0' and '/'. Period. It has no idea of extensions, maximal component
>lengths, etc.
>
>Moreover, names returned by ->readdir() are not interpreted - they are
>responsibility of filesystem in question. Ditto for limits you place
>on the names acceptable for ->create(), ->mkdir(), etc. - it's up to
>filesystem.
>
>Same goes for the way you store and interpret symlinks - VFS has no
>business messing with that; that's what ->readlink() and ->follow_link()
>are for.
>
>_If_ you want to use "add magical 4 bytes to the end of component to
>indicate a symlink" - more power to you, but that's nothing but a
>detail of your filesystem layout. You are making a directory with
>both 'foo' and 'foo.!nk' invalid, but that's the matter of fsck for
>your filesystem and ability of fs driver to cope with such error
>gracefully.
Sounds great.
Now add this to NTFS, iso9660, and vfat, without directly modifying any of the three filesystems (otherwise you'd need to maintain patches for different versions of these filesystem drivers).
--
Stevie-O
Real programmers use COPY CON PROGRAM.EXE
On Thu, 13 Jun 2002, Stevie O wrote:
> >_If_ you want to use "add magical 4 bytes to the end of component to
> >indicate a symlink" - more power to you, but that's nothing but a
> >detail of your filesystem layout. You are making a directory with
> >both 'foo' and 'foo.!nk' invalid, but that's the matter of fsck for
> >your filesystem and ability of fs driver to cope with such error
> >gracefully.
>
> Sounds great.
>
> Now add this to NTFS, iso9660, and vfat, without directly modifying any of the three filesystems (otherwise you'd need to maintain patches for different versions of these filesystem drivers).
_I_ wouldn't need that since I'm not interested in internal business of
either of these filesystems (BTW, iso9660 is perfectly capable of supporting
symlinks - google for rockridge or just take a look at any "live fs" ISO
image from damn next to any distro).
And no, this stuff will stay on fs level. There will be no magic flag
saying "this fs has funny symlinks implementation". Consider that one
vetoed - and I _really_ doubt that going directly to Linus will give
you anything but LARTing in that case. Severe LARTing, judging by
the precedents...
If modifications for vfat and ntfs will happen to have common functions -
just put them into a library and use them in both filesystems. _If_ you
manage to convince the maintainers of VFAT and NTFS resp. that it's worth
the trouble, in the first place.