Re: [annoyance/non-feature] On OS X, every process is "occupying" CWD, making disk ejects impossible after cd'ing into them.

[Bob Proulx]

Danyel Bayraktar wrote:
> 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.

That would create regressions.  Consider the case where a shell
changes directory to some directory.  Then that directory is renamed.
Currently the shell having it as a current working directory will
continue to operate.  In your proposal the shell would suddenly fail
because it would not know the directory was renamed and would be
unable to return to it.

Bob

Re: [annoyance/non-feature] On OS X, every process is "occupying" CWD, making disk ejects impossible after cd'ing into them.

[L A Walsh]

Danyel Bayraktar wrote:

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…
  

Because it's not a bash problem?

In Windows, in their cmd.exe, if you cd to a directory,
you can't delete the directory (nor eject the device it
is on).

Re: [annoyance/non-feature] On OS X, every process is "occupying" CWD, making disk ejects impossible after cd'ing into them.

[Ángel]

On 2018-01-16 at 22:36 +0800, Danyel Bayraktar wrote:
> 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.

As Greg mentions, this is the same on other Unix systems too.
Now, as you mention, this has the drawback that you can't eject a disk
while you are at that folder. This is why [traditional] daemons chdir
to / as part of the usual procedure of going into background.

However, there may be cases where you want to keep that reference open.
For instance, the folder could be on an autofs mount, or you could be
working on a deleted folder.
The simpler use case for needing this however, would be a rename in the
folder path. Suppose you were working on /home/danyel/myfiles/
2017bugrports/bash/cwdspoof  Then you notice that there is a typo in the
path, and should be named "bugreports". You will find that you can
externally rename that folder with no ill-effects to the running bash.
$PWD will be wrong, but you can continue working in bash and launching
programs. Whereas with cwdspoof trying to use that console would fail.

There's also the efficiency argument about needing to traverse the
folder path before every command, which won't be that fast when network
is involved, or even a simple cdrom (although in that case it
could/should have been cached by the kernel).

Best regards

Re: [annoyance/non-feature] On OS X, every process is "occupying" CWD, making disk ejects impossible after cd'ing into them.

[Chet Ramey]

On 1/16/18 11:26 AM, Greg Wooledge wrote:
> On Tue, Jan 16, 2018 at 10:36:47PM +0800, Danyel Bayraktar wrote:
>> 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.
> 
> This is not unique to OS X.  Every single Unix-based operating system
> works like this.  It has nothing to do with bash.  This is nothing new.
> It has been this way since the dawn of time.  You are not going to
> change anything.

Regardless of the merits of this proposal, OS X presents its own peculiar
set of logistical problems.  Apple stopped updating bash at bash-3.2,
since they don't like GPLv3, so any change that touched the base system
in any permanent way would have to end up going through them to backport.

If you want to set your login shell to something else (e.g.,
/usr/local/bin/bash), you could experiment with making the changes yourself
and just install your locally-modified version there.

That would only help with your shell processes; any other system process
using the shell (or, say, Finder) would not be affected.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/

Re: [annoyance/non-feature] On OS X, every process is "occupying" CWD, making disk ejects impossible after cd'ing into them.

[Greg Wooledge]

On Tue, Jan 16, 2018 at 10:36:47PM +0800, Danyel Bayraktar wrote:
> 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.

This is not unique to OS X.  Every single Unix-based operating system
works like this.  It has nothing to do with bash.  This is nothing new.
It has been this way since the dawn of time.  You are not going to
change anything.

wooledg:~$ cd /tmp
wooledg:/tmp$ lsof -p $$
COMMAND  PIDUSER   FD   TYPE DEVICE SIZE/OFF NODE NAME
bash4331 wooledg  cwdDIR8,6 4096 11141121 /tmp
[...]

The cwd is actually held open by the process.  (It doesn't have to
be a shell; that was simply the easiest to demonstrate.)

The issue is EXTREMELY well-known.  There are operating system level
tools to help you identify which processes are holding a directory.
For example, fuser(1):

NAME
   fuser - identify processes using files or sockets
[...]

DESCRIPTION
   fuser displays the PIDs of processes using the specified files or  file
   systems.   In the default display mode, each file name is followed by a
   letter denoting the type of access:

  c  current directory.
  [...]


wooledg:~$ sudo fuser /tmp
[sudo] password for wooledg: 
/tmp: 4331c


Similar tools include lsof(1) (third party but very common) and fstat(1)
(BSD).

The fuser(1) command even has a -k (kill) option to send a signal to
every process that's holding a directory open.

Re: [annoyance/non-feature] On OS X, every process is "occupying" CWD, making disk ejects impossible after cd'ing into them.

[Danyel Bayraktar]

True, I did mention that in the stackexchange. Not sure it’s a bug, but it’s 
definitely a design flaw in my opinion.

However, Apple probably has no interest in fixing this as apps already depend 
on the behaviour. And in principle, as you do mention hacking, I’m not sure if 
disabling this “"feature”” by hacking it would even be desirable. I would want 
the OS to stop me from ejecting a disk when I’m currently in the process of 
e.g. writing to a file.

Altogether, the `cwdspoof` shopt flag seems to me the only viable solution, 
everything considered.

> On 17. Jan 2018, at 00:11, isabella parakiss  wrote:
> 
> hack the kernel and fix the bug in osx where it's supposed to be fixed
> 
> On 1/16/18, Danyel Bayraktar  wrote:
>> I asked on StackExchange prior to this:
>> 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.

Re: [annoyance/non-feature] On OS X, every process is "occupying" CWD, making disk ejects impossible after cd'ing into them.

[isabella parakiss]

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

On 1/16/18, Danyel Bayraktar  wrote:
> I asked on StackExchange prior to this:
> 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.

[annoyance/non-feature] On OS X, every process is "occupying" CWD, making disk ejects impossible after cd'ing into them.

[Danyel Bayraktar]

I asked on StackExchange prior to this: 
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.