[Bugs] #1551 UNSP: filestore.retrieve(): chmod() don't make sense
Sugar Labs Bugs
bugtracker-noreply at sugarlabs.org
Thu Nov 12 06:17:57 EST 2009
#1551: filestore.retrieve(): chmod() don't make sense
------------------------------------------+---------------------------------
Reporter: sascha_silbe | Owner: tomeu
Type: defect | Status: new
Priority: Unspecified by Maintainer | Milestone: Unspecified by Release Team
Component: sugar-datastore | Version: Git as of bugdate
Severity: Unspecified | Keywords:
Distribution: Unspecified | Status_field: Unconfirmed
------------------------------------------+---------------------------------
While fixing #1550, I stumbled over this code again:
{{{
# Try to hard link from the original file to the targetpath. This
can
# fail if the file is in a different filesystem. Do a symlink
instead.
try:
os.link(file_path, destination_path)
except OSError, e:
if e.errno == errno.EXDEV:
os.symlink(file_path, destination_path)
else:
raise
# Try to make the original file readable. This can fail if the
file is
# in a FAT filesystem.
try:
os.chmod(file_path, 0604)
except OSError, e:
if e.errno != errno.EPERM:
raise
}}}
I guess the chmod() is supposed to make the file readable to the caller in
case we use a symlink instead of a hardlink.
The permissions don't make much sense:
* allow read+write for the owner (data store user) - OK
* no access to the group - ?
* read access to world - overrides group settings
Was it supposed to be 0640 (rw- r-- ---) instead?
Why do we always do the chmod() instead of only when we actually symlink,
BTW? A hardlink doesn't share permissions, only data.
Do we support data stores on FAT filesystems at all? AFAICT our optimizer
will fail hard (at least in filestore.hard_link_entry()) on those.
--
Ticket URL: <http://bugs.sugarlabs.org/ticket/1551>
Sugar Labs <http://sugarlabs.org/>
Sugar Labs bug tracking system
More information about the Bugs
mailing list