New issue
Advanced search Search tips

Issue 920416 link

Starred by 2 users
Status: Assigned
Owner:
chirantan@chromium.org
Cc:
joelhockey@chromium.org
dgreid@chromium.org
tbuck...@chromium.org
rohi...@chromium.org
avkodipelli@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Bug



Sign in to add a comment

Crostini: file modify from terminal was saved despite the file system was unshared

Project Member Reported by sienkou@google.com, Jan 9 
Chrome Version: 73.0.3664.0
Chrome OS Version: 11552.0.0
Chrome OS Platform: Nautilus, Kevin
Network info: wifi

Please specify Cr-* of the system to which this bug/feature applies (add
the label below).

Steps To Reproduce:
(1) After Linux VM installation completes, open Files app, right click on any of the file system (I tried Downloads, USB), and choose Share with Linux
(2) Place some text files into the above share file systems
(3) From Linux terminal, cd to the share file system, say /mnt/chromeos/MyFiles/Downloads and vi the text file in step 2, modify the file, but don't save yet
(4) Open the chrome broswer, chrome://settings and remove the file share preference of the file system
(5) From the terminal, save the vi change

Expected Result:
 Changes should not be saved and appropriate error message is expected

Actual Result:
 a) Changes was saved. From terminal I also have access to the directory and file even though they should be un-shared already
 
 b) Open the file fro Files UI and the changes was saved

How frequently does this problem reproduce? Always

Comment 1 by dgreid@google.com, Jan 9 

I'm not sure how feasible this is. I don't know of a method for pulling the open file descriptor away from a process.

Comment 2 by dgreid@google.com, Jan 10

Labels: -M-73
Owner: chirantan@chromium.org
Status: Assigned (was: Untriaged)
We could also put up some ui to tell the user that we can't unshare in this case.

Comment 3 by chirantan@chromium.org, Jan 10 

Do you have the contents of /var/log/messages?  Likely the unshare failed because the file was still open and we just didn't show any UI for it.  This was one of the concerns I had brought up when we added the unshare path in the first place.

Comment 4 by joelhockey@chromium.org, Jan 10 

Chirantan and I experimented with this a little while back using MNT_DETACH if umount fails with EBUSY.  crosreview.com/1404454.  I can verify that it fixes the scenario described in this bug.  Chirantan was reluctant to add this code though - I think the concern was about data loss.

Comment 5 by sienkou@google.com, Jan 10

Labels: M-73
feedback link: https://listnr.corp.google.com/report/85898024649

Comment 6 by chirantan@chromium.org, Jan 10 

As expected the unmount is failing:


2019-01-09T13:48:49.380976-08:00 INFO seneschal[5582]: Received request to unshare path with server
2019-01-09T13:48:49.384788-08:00 ERR seneschal[5582]: Failed to unmount


Unfortunately that line that produces the failure is a LOG instead of a PLOG so we don't know why it failed but I would guess that it's likely EBUSY.
►

Sign in to add a comment