[delphizip] Re: Volume-readonly checking is too harsh, blocking writable situations.
- From: Xavier Mor-Mur <xmormur@xxxxxxxxxxxxx>
- To: delphizip@xxxxxxxxxxxxx
- Date: Wed, 29 Oct 2008 12:45:01 +0100
I think some check should be done.
Also we keep in mind some destination folders may have rights to create
and write but not to delete any file even those create for current process.
This type of situations may introduce unwanted results when trying to
update or re-compress an existing compressed file.
At the moment I add date and time to file name when destination is a
external ftp folder.
regards
Xavier Mor-Mur
En/na James Turner ha escrit:
> What method is currently used to determine ReadOnly status?
>
> I ran up against this problem some years ago. I can't remember what
> solution I chose eventually, but I would think that using the API
> function CreateFile with the flag CREATE_ALWAYS should work well,
> provided that a file name is chosen that isn't likely to conflict with
> anything. If the file is created (and then deleted) in the destination
> directory, it should be safe to assume that further write operations
> will succeed in that directory.
>
> -- James Turner
>
>
> Russell Peters wrote:
>
>> I had an idea that there might some situations where that test would be
>> invalid and no doubt more variations will occur in modern usage.
>> We added these tests when XP was young and they were designed to stop the
>> frustration of waiting for a long operation only to find that it could not
>> be written to its destination.
>> Because of no reported problems we kept it there.
>> I will remove it from the next release - if you comment out that clause does
>> it work reasonably?
>>
>> Russell Peters
>> On Wed, Oct 29, 2008 at 8:11 AM, Patrick Kolla <
>> patrick.kolla@xxxxxxxxxxxxxxxxxxxx> wrote:
>>
>>
>>
>>> Just downloaded the latest 179 download to verify its not an old bug,
>>> but still persisted, so I'm reporting it here:
>>>
>>> Unit ZMWrkr.pas:, function TZMWorker.CheckDestWritable tests:
>>>
>>> if XP and FVolumeReadOnly then // XP only - true if volume Read-Only
>>> begin
>>> if not NoExc then
>>> raise EZipMaster.CreateResDrive( DS_NotChangeable, xname);
>>> exit;
>>> end;
>>>
>>> This is wrong in some situations - on NTFS volumes, writable volumes
>>> might be mounted into folders of readonly drives (instead of drive
>>> letters).
>>> Another example would be Windows PE 2.0 (Vista based) bootable CDs where
>>> a RAM disk gets mounted on a drive that is detected as readonly but that
>>> is writable.
>>>
>>> And after debugging bootable CDs for some hours to track this error,
>>> I'ld say that "cannot write to" is just not the proper error message for
>>> this case, at least a hint at the reason, and that you cannot cannot,
>>> but do not want to would be nice, like "The target volume is readonly;
>>> will not write to %s".
>>>
>>> -----------
>>> To unsubscribe from this list, send an empty e-mail
>>> message to:
>>> delphizip-request@xxxxxxxxxxxxx
>>> and put the word unsubscribe in the subject.
>>>
>>>
>>>
>> -----------
>> To unsubscribe from this list, send an empty e-mail
>> message to:
>> delphizip-request@xxxxxxxxxxxxx
>> and put the word unsubscribe in the subject.
>>
>>
>>
> -----------
> To unsubscribe from this list, send an empty e-mail
> message to:
> delphizip-request@xxxxxxxxxxxxx
> and put the word unsubscribe in the subject.
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.175 / Virus Database: 270.8.4/1754 - Release Date: 29/10/2008
> 7:45
>
>
-----------
To unsubscribe from this list, send an empty e-mail
message to:
delphizip-request@xxxxxxxxxxxxx
and put the word unsubscribe in the subject.
Other related posts:
