Hello Scott,
> That would also require an API change that would break all existing
> applications. But there is already a workaround in the SVN version (it
> just tries the fopen() call directly and sees if it succeeds).
>
> -Scott
thanks for your answer. I see the problem, I only had a (maybe irrational)
concern to open something read-write which should in most cases only be read.
By the way: The documentation to File::writeBlock says "If the file is
currently only opened read only -- i.e. readOnly() returns true -- this
attempts to reopen the file in read/write mode."
I think, it would be a good compromise to open a file read-only in the
constructor and only reopen it read-write when calling modifying functions.
Unfortunately File::writeBlock is not implemented as the comment implies.
But as said above this is maybe not an issue as the time of last modification
seems not to be changed as long as there is no real write access.
Now I replaced in file taglib/toolkit/tfile.cpp:
File::File(const char *file)
{
d = new FilePrivate(::strdup(file));
d->readOnly = !isWritable(file);
d->file = fopen(file, d->readOnly ? "r" : "r+");
if(!d->file)
debug("Could not open file " + String(file));
}
with this version from svn:
File::File(const char *file)
{
d = new FilePrivate(::strdup(file));
// First try with read/write mode, if that fails, fall back to read only.
// We can't use ::access() since that works in odd ways on some file
systems.
d->file = fopen(file, "rb+");
if(d->file)
d->readOnly = false;
else
d->file = fopen(file,"rb");
if(!d->file)
debug("Could not open file " + String(file));
}
Indexing the files on the samba share now works perfectly.
Maybe this fix could be included in Debian, Christopher?
Many thanks again and best regards
Stefan
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
