Closed Bug 58309 Opened 24 years ago Closed 16 years ago

XP File locking - add Lock() and Unlock() to the nsILocalFile (or nsIFile) interface.

Categories

(Core Graveyard :: File Handling, defect, P3)

x86
All
defect

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: sspitzer, Unassigned)

Details

(Whiteboard: WONTFIX?)

this has come up a bunch of times, but I don't think there is a bug for it. I think we need to add Lock() and Unlock() to the nsILocalFile (or nsIFile) interface. the implementations would vary per platform. (pity the person who was to deal with NFS) some files I know we'd want to lock: history local mail folders bookmarks I'm not sure if win32 and mac have this problem, but on linux you can easily run several instances of mozilla and corrupt these files. in 4.x, we has a .netscape/lock, as global lock over all the users data. adding bienvenu and mscott, they might own some mail bugs that depend on this.
It's not a matter of pitying whoever deals with NFS, it's a matter of dealing with the fact that you can't have mandatory file locking on all platforms/filesystems, or even reliable advisory locking. I don't think .netscape/lock was a locked file: I think it used the atomic nature of link(2)/symlink(2) to ensure that it couldn't race undetected with another process creating it. We can do the same thing, here, if that's what you want, but I don't think we should put Lock/Unlock interfaces on nsILocalFile for it. (Whether or not we need those methods _sounds_ like a different bug, perhaps.) Do we want a new nsIAtomicLocalFile interface? An nsAtomicLocalFile that implements nsILocalFile?
Status: NEW → ASSIGNED
what about major platforms like Mac/WinNT/Linux/Solaris? I'm wondering if we could do some sort of advisory locking on these platforms, and then do "fake" locking on other platforms, where we create a dud file next to the file we're trying to lock.. if the dud file exists, then the real file is locked. it doesn't have to be a great system, because all we really want is a way for mozilla to know that it can't open a file because another mozilla might be using it.
To the orphanage, in the off-chance that someone else cares enough to fix it in the future. (The profile-locking code probably has good leads.)
Assignee: shaver → nobody
Status: ASSIGNED → NEW
Product: Browser → Seamonkey
Component: General → File Handling
Product: SeaMonkey → Core
QA Contact: doronr → file-handling
Summary: XP File locking → XP File locking - add Lock() and Unlock() to the nsILocalFile (or nsIFile) interface.
Whiteboard: WONTFIX?
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.