Activity log for bug #738310

Date Who What changed Old value New value Message
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.