Member Avatar for mouse_8b

Hello,
Short Story: A file on my computer is disappearing when accessed by another user on the network.

Long Story: I have a partition on my computer (E:) that I share the root of on my work network. In the root directory, there is (was) a MapPoint file (E:/mapfile.ptm). Sometimes, when someone is using that file on a different computer and tries to save it, it shows this error:

"A file by this name already exists and is read-only or locked by some other means. In order to save it, type a different name."

However, even if you try to save as a different name or in a different location (including locally to the computer using the file), the same error comes up, and the file disappears from the file system on my computer.

This has happened multiple times. At first, I thought I had accidentally deleted the file myself. After 2 more times though, including a "now you see it, now you don't" experience today, I know it is not a user error from either party. My best guess is that restarting my computer is the root of the problem. I restarted while the file was open on the other computer, and I suppose when the other user tried to save, the file handler was confused since the network resource had been reset. I would expect this to lead to not being able to save a file, but deleting the file off of the shared drive makes no sense.

More Data:
The file was open on the other computer when I restarted my computer this morning. After the error message on attempted save, I made sure the file still existed on my machine where it belonged, and it did appear in the file list. Moments later, after attempted save-as, the file does not show in the file list in explorer.
I started playing with it after that. I restarted my computer with the file open on the other computer. If I use Windows Explorer to view the networked drive before I try to save it, it seems to work fine. How is the file being deleted when the program thinks that it can't access the file?

  • 3 Contributors
  • 2 Replies
  • 198 Views
  • 5 Days Discussion Span
  • Latest Post Latest Post by jingda

Dani AI

Generated

Brief expert summary tied to the thread: ’s “now you see it, now you don’t” symptom plus the “file already exists / read-only or locked” error points at a safe-save/replace sequence combined with a network-side cache/lock reset. The observation that opening or refreshing the share in Explorer before the remote save often avoids the problem is a key diagnostic clue. Comments from (offline‑cache suspicion) and (sharing settings) are relevant, but deeper evidence is needed before disabling services.

How this typically happens (high level, non‑conclusive): many Windows apps write a temporary file then rename it to the final name. If the server’s file handles or opportunistic locks (oplocks) are broken by a restart or client caching, the client’s rename/replace step can fail or cause the original to be removed unexpectedly. Offline Files/CSC, client caching, or a misbehaving application (MapPoint) are plausible contributors; none should be asserted without traces.

Troubleshooting checklist that produces evidence (passive phrasing):

  • Reproduce the problem using a disposable copy of the .ptm to avoid data loss.
  • Check open sessions on the host (Computer Management → Shared Folders → Open Files, or net file) at the time of the save to see which machine/account holds the handle.
  • Enable object‑deletion auditing and add a SACL on the folder for Delete/DeleteSubfolders — the Security log will record which account/process performed the delete.
  • Capture a ProcMon trace (Sysinternals) on the host and, if possible, the client while reproducing; filter on the filename and watch CreateFile/Rename/Delete operations and temp‑file names.
  • Inspect Sync Center/conflict logs if Offline Files is enabled, and look for hidden/temp files (common temp patterns like leading ~ or .tmp).

Short mitigations and next steps: avoid restarting the machine that hosts the share while remote edits are open; check and close open files before reboot; use server-side shadow copies or a dedicated file server for shared MapPoint files. ProcMon traces or Security events will identify whether the delete is performed by the client app, the OS cache layer, or another process, which then determines whether an app update, server setting change (oplocks/caching), or vendor escalation is required.

Recommended Answers

All 2 Replies

Member Avatar for flagstar

Well you could try to disable file sharing first. It might have something to do with the program itself not properly save the file before and now it can't even detected files that it supported. Move the faulty files to somewhere else which not in shared directory.

Member Avatar for jingda

This is a common problem, try searching use the search bar at the top to check whether is there any similar threads like yours. Does other users on other computers have the same permissions as you to edit the file?


Edit: Are you using vista? A quick check on the internet reveal that most of this problem happens to vista users. Try to disable offline files. Go and search for offline files in start and disable it. Try again.

Edited by jingda because: n/a
Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.