| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 3445.1 | Answer may be delayed... | ucxaxp.ucx.lkg.dec.com::TIBBERT | Lee Tibbert, DTN 226-6115 | Tue Dec 19 1995 20:32 | 31 |
| 3445.2 | More data | CSC32::R_WILLIAMS | | Thu Dec 21 1995 11:22 | 15 |
| 3445.3 | It's a Files-11 `optimization'. | LASSIE::GEMIGNANI | | Thu Dec 21 1995 14:49 | 8 |
| 3445.4 | Thanks. | CSC32::R_WILLIAMS | | Thu Dec 21 1995 15:08 | 5 |
| 3445.5 | is there something else we can do? | UTRTSC::KNOPPERS | Oswald Knoppers | Fri Nov 15 1996 07:06 | 30 |
| 3445.6 | No change | LADDIE::TIBBERT | Lee Tibbert, DTN 226-6115 | Fri Nov 15 1996 11:50 | 13 |
| 3445.7 | | UTRTSC::KNOPPERS | Oswald Knoppers | Mon Nov 18 1996 02:23 | 13 |
| 3445.8 | | UCXAXP::GEMIGNANI | | Fri Dec 06 1996 16:30 | 3 |
| 3445.9 | issue comes up again... | UTRTSC::KNOPPERS | Oswald Knoppers | Fri Mar 07 1997 10:45 | 20 |
| >Ye I understand why this happens. But somehow Multinet doesn't seem to
>suffer from this problem. I guess they just send the modification date back
>as VMS provides is. This obviously means that the client side won't notice
>when new files are created in this directory.
To follow up on myself. I have now a customer where this is becoming a big
issue. They are threatening to move to a non-digital platform for there
disk servers. Anyway, I have verified my above assumption and indeed
Multinet doesn't notice when a new file is put in the directory.
I tried to explain to my customer that UCX actually makes the best decision
by returning 'just now' as directory modification date but somehow my
customer is not convinced... How odd :-).
My question is, how much work ($$$) would it cost to put some option in our
NFS server to emulate Multinet's behaviour in this respect?
Thanks,
Oswald
|
| 3445.10 | Use set vol/retent | EVMS::EVERHART | | Fri Mar 07 1997 13:52 | 27 |
| Aren't there some tricks that can be played by way of getting a
blocking AST on a directory so that anyone accessing it trips this
doorbell and thus directory mods can be tracked?
Also I have an intercept that looks at opens and have noticed that
directory ID's in there at least some of the time, and you can
see directory opens going by also. (This is looking before the xqp
level, below RMS.) If the DID isn't there the FID is and can be
backtraced if need be and the disk structure's ok.
If you keep track of how often someone asks for directory info,
you could trigger either of these kinds of monitoring techniques to
tell when the directory gets altered.
Alternatively you could use the revision date using set vol/retention
and report the expiration date of the directory. Then the user can
set how granular his updates need to be (tho I could wish the name
were something other than expiration time.)
I have checked and find that the expiration date for a dir does get
updated when files are added to it etc.
By using retention time you can let the user control how granular the
time will be and give a meaningful alterative to "now" all the time
as dir update time. If the expiration time is zero, use the
current behavior.
|
| 3445.11 | retention doesn't work for me... | UTRTSC::KNOPPERS | Oswald Knoppers | Tue Mar 11 1997 03:42 | 18 |
| > Alternatively you could use the revision date using set vol/retention
> and report the expiration date of the directory. Then the user can
> set how granular his updates need to be (tho I could wish the name
> were something other than expiration time.)
>
> I have checked and find that the expiration date for a dir does get
> updated when files are added to it etc.
I don't seem to be able to do this. I have tried setting a retention date
on a volume, but the expiration date of directory files are not updated
when adding or removing files from that directory.
Anyway, could someone from engineering please comment on this 'new feature
request'?
Thanks,
Oswald
|