2011-03-19 17:03:33 |
André Madureira |
bug |
|
|
added bug |
2011-03-19 17:03:33 |
André Madureira |
attachment added |
|
Access Time of SMBNETFS compared to MOUNT.CIFS https://bugs.launchpad.net/bugs/738310/+attachment/1921110/+files/Error.xls |
|
2011-03-19 17:03:53 |
André Madureira |
affects |
ubuntu |
smbnetfs (Ubuntu) |
|
2011-03-19 17:04:45 |
André Madureira |
description |
Hello,
I tried opening remote files (via SAMBA on a Windows XP Professional CPU) via KIO SLAVES in my Kubuntu distribution and I couldn't open most of them because a lot of aplcations don't have support for KIO SLAVES smb:// protocol (and I don't know why - it's a lot more efficient to access a remote path directly than mounting it with CIFS or something related...)...
PROBLEM:
Anyway, when I open any file via SMBNETFS mounting filesystem, I have a delay when compared to the CIFS mounting (to mount via CIFS I used MOUNT.CIFS)... So is this delay related to the WORKGROUP scan or is it a bug of the program?
SOLUTION:
Use CIFS similar way of mounting remote SAMBA paths on SMBNETFS to speed it up...
SOME IMPORTANT INFORMATION:
In the attachments are a XLS file that has some information about how this delay affected the accessing speed...
Thanks for your attention and help,
André M. |
Hello,
I tried opening remote files (via SAMBA on a Windows XP Professional CPU) via KIO SLAVES in my Kubuntu distribution and I couldn't open most of them because a lot of aplcations don't have support for KIO SLAVES smb:// protocol (and I don't know why - it's a lot more efficient to access a remote path directly than mounting it with CIFS or something related...)...
PROBLEM:
Anyway, when I open any file via SMBNETFS mounting filesystem, I have a delay when compared to the CIFS mounting (to mount via CIFS I used MOUNT.CIFS)... So is this delay related to the WORKGROUP scan or is it a bug of the program?
SOLUTION:
Use CIFS similar way of mounting remote SAMBA paths on SMBNETFS to speed it up...
SOME IMPORTANT INFORMATION:
In the attachments there is a XLS file that has some information about how this delay affected the accessing speed...
Thanks for your attention and help,
André M. |
|
2011-03-19 17:06:15 |
André Madureira |
description |
Hello,
I tried opening remote files (via SAMBA on a Windows XP Professional CPU) via KIO SLAVES in my Kubuntu distribution and I couldn't open most of them because a lot of aplcations don't have support for KIO SLAVES smb:// protocol (and I don't know why - it's a lot more efficient to access a remote path directly than mounting it with CIFS or something related...)...
PROBLEM:
Anyway, when I open any file via SMBNETFS mounting filesystem, I have a delay when compared to the CIFS mounting (to mount via CIFS I used MOUNT.CIFS)... So is this delay related to the WORKGROUP scan or is it a bug of the program?
SOLUTION:
Use CIFS similar way of mounting remote SAMBA paths on SMBNETFS to speed it up...
SOME IMPORTANT INFORMATION:
In the attachments there is a XLS file that has some information about how this delay affected the accessing speed...
Thanks for your attention and help,
André M. |
Hello,
I tried opening remote files (via SAMBA on a Windows XP Professional CPU) via KIO SLAVES in my Kubuntu distribution and I couldn't open most of them because a lot of aplcations don't have support for KIO SLAVES smb:// protocol (and I don't know why - it's a lot more efficient to access a remote path directly than mounting it with CIFS or something related...)...
PROBLEM:
Anyway, when I open some files with some specific programs (until now I've only see this happen with GNOME Mplayer and LibreOffice) via SMBNETFS mounting filesystem, I have a delay when compared to the CIFS mounting (to mount via CIFS I used MOUNT.CIFS)... So is this delay related to the WORKGROUP scan or is it a bug of the program?
SOLUTION:
Use CIFS similar way of mounting remote SAMBA paths on SMBNETFS to speed it up...
SOME IMPORTANT INFORMATION:
In the attachments there is a XLS file that has some information about how this delay affected the accessing speed...
Thanks for your attention and help,
André M. |
|