On Thu, 10 Nov 2005 11:43:35, Alexey Proskuryakov <email@hidden>
wrote:
> On 10.11.2005 01:53, "John Stiles" <email@hidden> wrote:
>
>> The easiest way to learn whether a file can be written to is to open the file
>> with write permission and then immediately close it. If you were able to open
>> it, it's writable. This is safe to do and doesn't take a long time.
>
> According to <http://developer.apple.com/technotes/fl/fl_37.html>, opening
> files on read-only volumes with fsRdWrPerm of fsWrPerm should succeed,
> falling back to read/deny-write or similar. Ancient documentation, but still
> true for some file systems (AFP, but not SMB, rdar://3755430).
That's true as of remote AFP volumes, it is not the case with local
volumes, see below.
> -------------------------------------------------
> An open with write permission request (fsCurPerm, fsWrPerm, fsRdWrPerm, or
> fsRdWrShPerm) does not fail on a locked volume and the write bit in
> ioFCBFlags returned by PBGetFCBInfo will be set indicating that data can be
> written to the file. As noted in Inside Macintosh: Files on page 2-8, you
> won't discover this until you receive an error (either vLckdErr or wPrErr)
> on the first call that attempts to write to the file or change the file's
> logical or physical end-of-file. You can preflight for this condition by
> calling PBHGetVInfo and checking the hardware and software locked bits in
> ioVAtrb.
> -------------------------------------------------
This quote is about local volumes. Notice, it doesn't mention fallback
from fsWrPerm to fsRdPerm. It means quite the opposite: the fsWrPerm
is *granted*, i.e. write call is ok and whether it'll fail or not
depends upon the current lock state (hardware or software) of the
volume at the time of write.
> -------------------------------------------------
> fsRdWrPerm is also retried as read-only, to simulate the case where a file
> is being opened from a locked disk. Elsewhere, it's pointed out that
> fsRdWrPerm is granted even if the volume is locked, and that an error won't
> be returned until a PBWrite (or PBSetEOF or PBAllocate) call is made. The
> same is now true for a read-only folder on an AppleShare volume.
> -------------------------------------------------
This quote is about remote AFP volumes. Notice that it is quite
different from the above, the "simulation" is not quite complete.
fsWrPerm is not granted, thus write operation will always fail
even if the volume is somehow unlocked at the time of write (if
there are means to achieve this at all). The other minor
difference is the error that'll return on attempt to write:
it will be "permission" error, not "locked" or "write protected"
error.
The whole idea of granting fsWrPerm on locked volumes makes some
sense on volumes which can be locked/unlocked anytime: by the time
of write volume lock state might be different than what it was by
the time of open. Think of write protected switch on diskettes that
could be ejected/reinserted without volume unmounting. Or write
protected switch on some USB flash drives. Or software lock/unlock.
On media like CD-R or DVD-R this model doesn't make much sense.
It'd be reasonable for file manager to be aware of this and never
"grant" fsWrPerm (and thus *not* fallback to fsRdPerm) on such
media, if it doesn't do this already :).
Yep, the technote is interesting and somewhat ancient. It lacks
one important translation: file manager model <-> bsd model, the
translation that could change the whole story quite dramatically.
Mike
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden
This email sent to email@hidden
