Re: [cobalt-users] Raq4-Site Admin

[Tim Dunn <tdunn@xxxxxxxxxxxxxxxxxxx>]

> [if someone] is uploading a file called "file.html". Is it possible
> for the other siteadmin to delete/change the file ?

> It is currently not possible !  How to do it possible ?

You must really like the smell of cordite and shoe polish. =)

> What about the server admin ?  admin cant either !

While unix is a multi-user operating system, I doubt it has any means
to protect multiple users (or processes) from stomping over one another.

Having said that, what you will get is a case of "last man standing".

1) User 1 loads the file into editor.  The file itself is untouched (well,
   the access time is updated, but that's on the inode).  A *COPY* of the
   file is loaded into the user's space by the editor.  The editor may 
   make a temporary file, but that's up to the programmer.

2) User 2 loads the file into editor.  Another *COPY* is loaded into User 2's
   user space in memory (virtual or real) and possibly another tmp file is
   generated.  User 2 makes edits.

3) User 1 makes edits.

4) At this point, assuming neither user has saved, the file on disk is still
   untouched.

5) User 1 saves.

6) User 2 saves.  At this point, reality rears its ugly head.  User 1's version
   in memory is now completely out of date.  Moreover, User 2 has no idea s/he
   has just blown away User 1's work.

7) If User 2 terminates the editor with a simple "quit" command, then what's on
   disk is User 2's version.  If User 1 ends the editor with "save and exit "
   (ZZ on vi, f'instance), then User 2's changes now get overwritten.

That's a simple example with a static file.  If we use the situation you
have above, it gets worse.

1) User 1 uploads the file.  Assuming it's a sizable upload, it will take
   some significant (for this example) interval of time.

2) User 2 opens the file.  At the point in time User 2 opens the file
   (loads a COPY into memory), the file is still being uploaded.  User
   2's file is truncated.

3) User 2 edits the file and saves.  At this point, the file will either
   have finished uploading or not.

   a) If the file has finished uploading, User 2's save will completely
      overwrite the uploaded file.  Remember that User 2 loaded an
      INCOMPLETE file in step 2, so it's doubtful s/he will have a
      complete file to save at this point.

   b) If the file is not finished uploading, then it's a crapshoot depending
      on how the different software authors implemented their [f]opens and 
      [f]writes.  

	If the uploading program actually saves to tmpfile then moves the 
	tmpfile to the destination after successful upload, then User 2's		edits are toast, and the upload is as User 1 expects.

	If the editor creates a whole new entry in the directory structure, 
	then the uploading program will go blithely and blissfully on its
	way, dumping data to parts on disk never to be accessed again.
	User 2's version of the file is what's on disk.

	If the editor and the uploading programs both attempt to use the
	filesystem in place, then ... well, I don't know what will happen,
	but i'm sure it's not going to either User 1 or User 2's version.

tim

-- 
Mechanical Engineers build weapons.  Civil Engineers build targets.