[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [annoyance/non-feature] On OS X, every process is "occupying" CWD, m

From: isabella parakiss
Subject: Re: [annoyance/non-feature] On OS X, every process is "occupying" CWD, making disk ejects impossible after cd'ing into them.
Date: Tue, 16 Jan 2018 16:11:10 +0000

hack the kernel and fix the bug in osx where it's supposed to be fixed

On 1/16/18, Danyel Bayraktar <address@hidden> wrote:
> I asked on StackExchange prior to this:
> https://apple.stackexchange.com/questions/310965/stop-iterm2-from-using-disk-disk-cannot-be-ejected
> <https://apple.stackexchange.com/questions/310965/stop-iterm2-from-using-disk-disk-cannot-be-ejected>
> Initially I thought it was specific to the terminal emulator, but it is
> actually due to the design of OS X. My problem is that when cd’ing into the
> external drive to run an `ls`, I’m not really “using” it and should be able
> to eject it. The eject should only be impossible for the time span a process
> is actually running.
> So my proposal would be to get rid of this annoyance:
> Bash should idle in (e.g.) /tmp or /var/folders/xyz, i.e. occupy that file
> as ‘CWD’ towards the OS, but obviously not expose this to depending code, so
> still spawn every child process/builtin/keyword inside the (memory-stored)
> cwd which will be updated with `cd` and used throughout.
> The drawbacks of this are apparent: `lsof` would show a random irrelevant
> folder as `cwd` for bash and as such, would be backward incompatible. This
> could be mitigated by 1) only enabling this in OS X (I do remember disks can
> be ejected even if bash is occupying them), or (ill-performing), 2) only for
> external drives. Ill-performing because this will require checks after
> almost every CWD modification.
> 3) Honestly, the most obvious and backward-compatible solution would be to
> put this behind a shopt option, e.g. ‘shopt -s cwdspoof’. I don’t see any
> reason why this wouldn’t be feasible…
> This is my first e-mail here — I would love to help implement this if you
> give me some pointers and a contribution guide.
> Best regards,
> Danyel.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]