Yesterday I restructured an archive folder on one of my shared drives.
It has so many sub-folders and files it took me most of the day.
Today I accessed this archive folder from another PC and the structure
I see is as it was before I started restructuring yesterday. When I
try to open a file on this phantom structure of the past it won't
open.
I go back to the machine the shared drive is on and all is a expected
and as it should be after yesterday's restructuring.
Restarting all PCs, shutting down then restarting all PCs has no
effect. Still the same disparity showing.
Restarting all PCs, shutting down then restarting all PCs has no
effect. Still the same disparity showing.
Yesterday I restructured an archive folder on one of my shared drives.
It has so many sub-folders and files it took me most of the day.
Today I accessed this archive folder from another PC and the structure
I see is as it was before I started restructuring yesterday. When I
try to open a file on this phantom structure of the past it won't
open.
I go back to the machine the shared drive is on and all is a expected
and as it should be after yesterday's restructuring.
On 30 Apr 2022 at 11:21:37 BST, "Mike Halmarack"
<mikehalmarack@gmail.com> wrote:
Yesterday I restructured an archive folder on one of my shared drives.
It has so many sub-folders and files it took me most of the day.
Today I accessed this archive folder from another PC and the structure
I see is as it was before I started restructuring yesterday. When I
try to open a file on this phantom structure of the past it won't
open.
I go back to the machine the shared drive is on and all is a expected
and as it should be after yesterday's restructuring.
What does a third, definitely-hasn't-cached-the-folder computer see?
That'll clear up whether it's a client or server side cockup.
Cheers - Jaimie
In article <843q6hdtd2bnsoviottcr2p5c3vtn3ocug@4ax.com>, Mike Halmarack >wrote...
Yesterday I restructured an archive folder on one of my shared drives.
It has so many sub-folders and files it took me most of the day.
Today I accessed this archive folder from another PC and the structure
I see is as it was before I started restructuring yesterday. When I
try to open a file on this phantom structure of the past it won't
open.
I go back to the machine the shared drive is on and all is a expected
and as it should be after yesterday's restructuring.
Restarting all PCs, shutting down then restarting all PCs has no
effect. Still the same disparity showing.
Curious, and interesting - something I've never seen.
Are you accessing the folder via network sharing notation (e.g. >\\myothermachine\sharename) or as a Mounted drive? If the latter, then >deleting the mount (net use X: \delete -- where X is the local drive name) and >then mounting it again (possibly with a different local letter) could well fix >it? Maybe delete the share at the source, then re-share it with a different >share name?
Mike Halmarack wrote:
Restarting all PCs, shutting down then restarting all PCs has no
effect. Still the same disparity showing.
Maybe caching of offline files is enabled, and has got confused?
In article <843q6hdtd2bnsoviottcr2p5c3vtn3ocug@4ax.com>, Mike Halmarack wrote...
Yesterday I restructured an archive folder on one of my shared drives.
It has so many sub-folders and files it took me most of the day.
Today I accessed this archive folder from another PC and the structure
I see is as it was before I started restructuring yesterday. When I
try to open a file on this phantom structure of the past it won't
open.
I go back to the machine the shared drive is on and all is a expected
and as it should be after yesterday's restructuring.
Restarting all PCs, shutting down then restarting all PCs has no
effect. Still the same disparity showing.
Curious, and interesting - something I've never seen.
Are you accessing the folder via network sharing notation (e.g. \\myothermachine\sharename) or as a Mounted drive? If the latter, then deleting the mount (net use X: \delete -- where X is the local drive name) and
then mounting it again (possibly with a different local letter) could well fix
it? Maybe delete the share at the source, then re-share it with a different share name?
In article <843q6hdtd2bnsoviottcr2p5c3vtn3ocug@4ax.com>, Mike Halmarack wrote...
Yesterday I restructured an archive folder on one of my shared drives.
It has so many sub-folders and files it took me most of the day.
Today I accessed this archive folder from another PC and the structure
I see is as it was before I started restructuring yesterday. When I
try to open a file on this phantom structure of the past it won't
open.
I go back to the machine the shared drive is on and all is a expected
and as it should be after yesterday's restructuring.
Restarting all PCs, shutting down then restarting all PCs has no
effect. Still the same disparity showing.
Curious, and interesting - something I've never seen.
Are you accessing the folder via network sharing notation (e.g. \\myothermachine\sharename) or as a Mounted drive? If the latter, then deleting the mount (net use X: \delete -- where X is the local drive name) and
then mounting it again (possibly with a different local letter) could well fix
it? Maybe delete the share at the source, then re-share it with a different share name?
In article <MPG.3cd735a2dfe1f1449899e4@news.eternal-september.org>, Philip Herlihy wrote...
In article <843q6hdtd2bnsoviottcr2p5c3vtn3ocug@4ax.com>, Mike Halmarack wrote...
Yesterday I restructured an archive folder on one of my shared drives.
It has so many sub-folders and files it took me most of the day.
Today I accessed this archive folder from another PC and the structure
I see is as it was before I started restructuring yesterday. When I
try to open a file on this phantom structure of the past it won't
open.
I go back to the machine the shared drive is on and all is a expected
and as it should be after yesterday's restructuring.
Restarting all PCs, shutting down then restarting all PCs has no
effect. Still the same disparity showing.
Curious, and interesting - something I've never seen.
Are you accessing the folder via network sharing notation (e.g. \\myothermachine\sharename) or as a Mounted drive? If the latter, then deleting the mount (net use X: \delete -- where X is the local drive name) and
then mounting it again (possibly with a different local letter) could well fix
it? Maybe delete the share at the source, then re-share it with a different
share name?
(This replyk seems not to have got through, though it was sent. Sending again:)
Digging around, I see the "Advanced Sharing" dialogue has "Caching" options. Drill down from the "Properties" dialogue accessed by right-clicking the folder
you wish to share. If you turn the caching off (perhaps temporarily) that might fix it. It does sound like a corrupted cache.
In article <MPG.3cd871db9a2b4b729899e6@news.eternal-september.org>, Philip >Herlihy wrote...
In article <MPG.3cd735a2dfe1f1449899e4@news.eternal-september.org>, Philip >> Herlihy wrote...
In article <843q6hdtd2bnsoviottcr2p5c3vtn3ocug@4ax.com>, Mike Halmarack
wrote...
Yesterday I restructured an archive folder on one of my shared drives. >> > > It has so many sub-folders and files it took me most of the day.
Today I accessed this archive folder from another PC and the structure >> > > I see is as it was before I started restructuring yesterday. When I
try to open a file on this phantom structure of the past it won't
open.
I go back to the machine the shared drive is on and all is a expected
and as it should be after yesterday's restructuring.
Restarting all PCs, shutting down then restarting all PCs has no
effect. Still the same disparity showing.
Curious, and interesting - something I've never seen.
Are you accessing the folder via network sharing notation (e.g.
\\myothermachine\sharename) or as a Mounted drive? If the latter, then >> > deleting the mount (net use X: \delete -- where X is the local drive name) and
then mounting it again (possibly with a different local letter) could well fix
it? Maybe delete the share at the source, then re-share it with a different
share name?
(This replyk seems not to have got through, though it was sent. Sending
again:)
Digging around, I see the "Advanced Sharing" dialogue has "Caching" options. >> Drill down from the "Properties" dialogue accessed by right-clicking the folder
you wish to share. If you turn the caching off (perhaps temporarily) that >> might fix it. It does sound like a corrupted cache.
Must have been stuck in a cache somewhere!
If the data on the drive is cached, so it can be accessed while
offline, where is the cache located?
Is it that the cache of the data is held on the basis of the drive
being turned off but the machine containing it still on and holding
the data elsewhere?
Or is it that the the whole of the data containing machine is turned
off and the cache is held locally on the potentially recipient
workstation?
In article <MPG.3cd735a2dfe1f1449899e4@news.eternal-september.org>, Philip >Herlihy wrote...
In article <843q6hdtd2bnsoviottcr2p5c3vtn3ocug@4ax.com>, Mike Halmarack
wrote...
Yesterday I restructured an archive folder on one of my shared drives.
It has so many sub-folders and files it took me most of the day.
Today I accessed this archive folder from another PC and the structure
I see is as it was before I started restructuring yesterday. When I
try to open a file on this phantom structure of the past it won't
open.
I go back to the machine the shared drive is on and all is a expected
and as it should be after yesterday's restructuring.
Restarting all PCs, shutting down then restarting all PCs has no
effect. Still the same disparity showing.
Curious, and interesting - something I've never seen.
Are you accessing the folder via network sharing notation (e.g.
\\myothermachine\sharename) or as a Mounted drive? If the latter, then
deleting the mount (net use X: \delete -- where X is the local drive name) and
then mounting it again (possibly with a different local letter) could well fix
it? Maybe delete the share at the source, then re-share it with a different >> share name?
(This replyk seems not to have got through, though it was sent. Sending >again:)
Digging around, I see the "Advanced Sharing" dialogue has "Caching" options. >Drill down from the "Properties" dialogue accessed by right-clicking the folder
you wish to share. If you turn the caching off (perhaps temporarily) that >might fix it. It does sound like a corrupted cache.
On 2 May 2022 at 14:39:43 BST, "Mike Halmarack"
<mikehalmarack@gmail.com> wrote:
If the data on the drive is cached, so it can be accessed while
offline, where is the cache located?
Is it that the cache of the data is held on the basis of the drive
being turned off but the machine containing it still on and holding
the data elsewhere?
Or is it that the the whole of the data containing machine is turned
off and the cache is held locally on the potentially recipient
workstation?
This - client side.
If I read correctly, using a third PC you've proved that there's just
one client machine with a bad idea of what's on the server? So whatever
has happened is on that client.
I'd suggest turning caching on (on that client) and off again, see if
that flushes it out.
Cheers - Jaimie
On 2 May 2022 13:53:35 GMT, Jaimie Vandenbergh
<jaimie@usually.sessile.org> wrote:
On 2 May 2022 at 14:39:43 BST, "Mike Halmarack"
<mikehalmarack@gmail.com> wrote:
If the data on the drive is cached, so it can be accessed while
offline, where is the cache located?
Is it that the cache of the data is held on the basis of the drive
being turned off but the machine containing it still on and holding
the data elsewhere?
Or is it that the the whole of the data containing machine is turned
off and the cache is held locally on the potentially recipient
workstation?
This - client side.
If I read correctly, using a third PC you've proved that there's just
one client machine with a bad idea of what's on the server? So whatever
has happened is on that client.
I'd suggest turning caching on (on that client) and off again, see if
that flushes it out.
Cheers - Jaimie
Thanks Jaime, that mostly cleared it up for practical puposes.
In a multi drive machine would the cache be held on the drive that
holds the OS by default?
On 2 May 2022 at 15:05:46 BST, "Mike Halmarack"
<mikehalmarack@gmail.com> wrote:
On 2 May 2022 13:53:35 GMT, Jaimie Vandenbergh
<jaimie@usually.sessile.org> wrote:
On 2 May 2022 at 14:39:43 BST, "Mike Halmarack"
<mikehalmarack@gmail.com> wrote:
If the data on the drive is cached, so it can be accessed while
offline, where is the cache located?
Is it that the cache of the data is held on the basis of the drive
being turned off but the machine containing it still on and holding
the data elsewhere?
Or is it that the the whole of the data containing machine is turned
off and the cache is held locally on the potentially recipient
workstation?
This - client side.
If I read correctly, using a third PC you've proved that there's just
one client machine with a bad idea of what's on the server? So whatever
has happened is on that client.
I'd suggest turning caching on (on that client) and off again, see if
that flushes it out.
Cheers - Jaimie
Thanks Jaime, that mostly cleared it up for practical puposes.
In a multi drive machine would the cache be held on the drive that
holds the OS by default?
I expect so, but only because Windows really doesn't like putting things anywhere else! No idea where.
Cheers - Jaimie
In article <jdadrjFrn58U1@mid.individual.net>, Jaimie Vandenbergh wrote...
On 2 May 2022 at 15:05:46 BST, "Mike Halmarack"
<mikehalmarack@gmail.com> wrote:
On 2 May 2022 13:53:35 GMT, Jaimie Vandenbergh <jaimie@usually.sessile.org> wrote:
On 2 May 2022 at 14:39:43 BST, "Mike Halmarack"
<mikehalmarack@gmail.com> wrote:
If the data on the drive is cached, so it can be accessed while
offline, where is the cache located?
Is it that the cache of the data is held on the basis of the drive
being turned off but the machine containing it still on and holding
the data elsewhere?
Or is it that the the whole of the data containing machine is turned >>> off and the cache is held locally on the potentially recipient
workstation?
This - client side.
If I read correctly, using a third PC you've proved that there's just
one client machine with a bad idea of what's on the server? So whatever >> has happened is on that client.
I'd suggest turning caching on (on that client) and off again, see if
that flushes it out.
Cheers - Jaimie
Thanks Jaime, that mostly cleared it up for practical puposes.
In a multi drive machine would the cache be held on the drive that
holds the OS by default?
I expect so, but only because Windows really doesn't like putting things anywhere else! No idea where.
Cheers - Jaimie
There's clearly a whole raft of stuff related to this that I've been unaware of. Most of the documentation online seems to relate to mapped drives (e.g. M:
\mystuff, rather than \\thatOtherBox\mystuff). You can configure a mapped drive to make files available offline, and it appears (from a quick survey) that the location for the cache is C:\Windows\CSC - which is an acronym for "Client Side Cache".
This article touches on all this: https://www.ubackup.com/windows-10/enable-offline-files-windows-10.html
In article <MPG.3cdb0d2257a30e19899e8@news.eternal-september.org>, Philip >Herlihy wrote...
In article <jdadrjFrn58U1@mid.individual.net>, Jaimie Vandenbergh wrote... >> >
On 2 May 2022 at 15:05:46 BST, "Mike Halmarack"
<mikehalmarack@gmail.com> wrote:
On 2 May 2022 13:53:35 GMT, Jaimie Vandenbergh
<jaimie@usually.sessile.org> wrote:
On 2 May 2022 at 14:39:43 BST, "Mike Halmarack"
<mikehalmarack@gmail.com> wrote:
If the data on the drive is cached, so it can be accessed while
offline, where is the cache located?
Is it that the cache of the data is held on the basis of the drive
being turned off but the machine containing it still on and holding
the data elsewhere?
Or is it that the the whole of the data containing machine is turned >> > >>> off and the cache is held locally on the potentially recipient
workstation?
This - client side.
If I read correctly, using a third PC you've proved that there's just >> > >> one client machine with a bad idea of what's on the server? So whatever >> > >> has happened is on that client.
I'd suggest turning caching on (on that client) and off again, see if >> > >> that flushes it out.
Cheers - Jaimie
Thanks Jaime, that mostly cleared it up for practical puposes.
In a multi drive machine would the cache be held on the drive that
holds the OS by default?
I expect so, but only because Windows really doesn't like putting things >> > anywhere else! No idea where.
Cheers - Jaimie
There's clearly a whole raft of stuff related to this that I've been unaware >> of. Most of the documentation online seems to relate to mapped drives (e.g. M:
\mystuff, rather than \\thatOtherBox\mystuff). You can configure a mapped >> drive to make files available offline, and it appears (from a quick survey) >> that the location for the cache is C:\Windows\CSC - which is an acronym for >> "Client Side Cache".
This article touches on all this:
https://www.ubackup.com/windows-10/enable-offline-files-windows-10.html
Another article (lost among the discarded tabs now) suggested that doing a >drive cleanup (from the Properties dialog, or using cleanmgr.exe, will clean >these caches if you drill down into the "clean up system files" level, and >include "temporary files". That's certainly plausible - if you have File >History enabled, and it's configured to work with an occasionally-connected >external drive, FH remembers/stores changed files until the drive is re- >connected. Those files can be purged by selecting "User File History" in that >list. (Not to be done without a good reason!)
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 61:07:51 |
| Calls: | 6,654 |
| Calls today: | 6 |
| Files: | 12,200 |
| Messages: | 5,331,524 |