Public bug reported:
Nautilus issues access() calls with the filenames that can't possibly
exist:
[pid 14422] access("MARK: nautilus nautilus_directory_emit_change_signals:
start ", F_OK) = -1 ENOENT (No such file or directory)
[pid 14422] access("MARK: nautilus nautilus_directory_emit_files_changed: start
", F_OK) = -1 ENOENT (No such file or directory)
[pid 14422] access("MARK: nautilus nautilus_directory_emit_files_changed: end
", F_OK) = -1 ENOENT (No such file or directory)
[pid 14422] access("MARK: nautilus nautilus_directory_emit_change_signals: end
", F_OK) = -1 ENOENT (No such file or directory)
This was created in 2006,
http://people.gnome.org/~federico/news-2006-03.html#09 to aid debugging,
however as access() is used for testing whether the object exists/can be
read/written by the process, these calls actually hit the underlying
filesystem.
While local filesystems are pretty quick to answer with ENOENT, the
remote filesystems, such as WebDAV over FUSE (with davfs2) will need to
check with the server for these files every time. davfs2 caches the
results, however if the remote filesystem was modified by copying a file
there, nautilus will hang until davfs2 finishes uploading the file and
is able to answer that access() call in case it was issued with the
current working dir set to a directory on davfs mount.
I think this method to gather performance information should be replaced
with something that does not use access() so that filesystem is not
touched at all.
ProblemType: Bug
DistroRelease: Ubuntu 13.04
Package: nautilus 1:3.6.3-0ubuntu9
ProcVersionSignature: Ubuntu 3.8.0-13.22-generic 3.8.3
Uname: Linux 3.8.0-13-generic x86_64
ApportVersion: 2.9.1-0ubuntu1
Architecture: amd64
Date: Wed Mar 20 11:15:26 2013
EcryptfsInUse: Yes
GsettingsChanges:
b'org.gnome.nautilus.window-state' b'geometry' b"'800x550+2+83'"
b'org.gnome.nautilus.window-state' b'maximized' b'true'
InstallationDate: Installed on 2013-01-04 (74 days ago)
InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Alpha amd64 (20130104)
MarkForUpload: True
SourcePackage: nautilus
UpgradeStatus: No upgrade log present (probably fresh install)
** Affects: nautilus (Ubuntu)
Importance: Undecided
Status: New
** Tags: amd64 apport-bug raring third-party-packages
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to nautilus in Ubuntu.
https://bugs.launchpad.net/bugs/1157621
Title:
access() calls included for debugging hang nautilus on webdav fuse
mount
Status in “nautilus” package in Ubuntu:
New
Bug description:
Nautilus issues access() calls with the filenames that can't possibly
exist:
[pid 14422] access("MARK: nautilus nautilus_directory_emit_change_signals:
start ", F_OK) = -1 ENOENT (No such file or directory)
[pid 14422] access("MARK: nautilus nautilus_directory_emit_files_changed:
start ", F_OK) = -1 ENOENT (No such file or directory)
[pid 14422] access("MARK: nautilus nautilus_directory_emit_files_changed: end
", F_OK) = -1 ENOENT (No such file or directory)
[pid 14422] access("MARK: nautilus nautilus_directory_emit_change_signals:
end ", F_OK) = -1 ENOENT (No such file or directory)
This was created in 2006,
http://people.gnome.org/~federico/news-2006-03.html#09 to aid
debugging, however as access() is used for testing whether the object
exists/can be read/written by the process, these calls actually hit
the underlying filesystem.
While local filesystems are pretty quick to answer with ENOENT, the
remote filesystems, such as WebDAV over FUSE (with davfs2) will need
to check with the server for these files every time. davfs2 caches the
results, however if the remote filesystem was modified by copying a
file there, nautilus will hang until davfs2 finishes uploading the
file and is able to answer that access() call in case it was issued
with the current working dir set to a directory on davfs mount.
I think this method to gather performance information should be
replaced with something that does not use access() so that filesystem
is not touched at all.
ProblemType: Bug
DistroRelease: Ubuntu 13.04
Package: nautilus 1:3.6.3-0ubuntu9
ProcVersionSignature: Ubuntu 3.8.0-13.22-generic 3.8.3
Uname: Linux 3.8.0-13-generic x86_64
ApportVersion: 2.9.1-0ubuntu1
Architecture: amd64
Date: Wed Mar 20 11:15:26 2013
EcryptfsInUse: Yes
GsettingsChanges:
b'org.gnome.nautilus.window-state' b'geometry' b"'800x550+2+83'"
b'org.gnome.nautilus.window-state' b'maximized' b'true'
InstallationDate: Installed on 2013-01-04 (74 days ago)
InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Alpha amd64 (20130104)
MarkForUpload: True
SourcePackage: nautilus
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1157621/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
