Jonathan Gilbert wrote:
> At 02:35 PM 30/10/2005 -0500, Michael Sinz wrote:
>
>>Jonathan Gilbert wrote:
>>[...]
>>
>>>Another minor issue is that the Linux man page for write() (section 2)
>>>indicates that there exist filesystems where write() doesn't even guarantee
>>>that space on the device has been reserved for the device, let alone that
>>>the data has been written. If the two file handles don't know about each
>>>other, then we also need to fsync() after every write(), and this creates a
>>>race condition in the absence of synchronization.
>>
>>Those two file handles due to symlinks to the same file will actually be
>>handled at the VFS/filesystem layer since they will open the same inode.
>>Even if the path is different and the name is different, filehandles really
>>only care about the inode it is talking to. So even hardlinks will be
>>handled correctly. (Softlinks are even more interesting since the VFS layer
>>does all of the softlink translation thus the final actual open operation
>>runs against the final target file/inode)
>
>
> This may be the case on a specific implementation, but is it a portable
> guarantee? I'm not sure where to check...
For softlinks that is basically POSIX. On hard links, they are directory
entries that point to the same inode. The only platform this is unclear for
that I know of is Windows. (Ok, maybe OS/400 - it has been many years since
I played with an AS/400 machine)
I windows had the same behavior but if I remember correctly, when you get a
write handle on a specific file, Windows tends to be much more restrictive as
to being able to get another, even from within the same process. But I have
not tested this and don't normally do software development for Windows.
--
Michael Sinz Technology and Engineering Director/Consultant
"Starting Startups" mailto:michael.sinz@sinz.org
My place on the web http://www.sinz.org/Michael.Sinz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Oct 30 21:29:24 2005